Method for predicting a travel time for a traffic route

ABSTRACT

A system for predicting a travel time for a traffic route is disclosed. The traffic route comprises one or more road segments. A predicted travel time for each of those segments is calculated based, in part, on traffic speed data for each of the one or more road segments. A total travel time is then calculated for the route, the total travel time including a predicted travel time for each of the one or more road segments

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation and claims the prioritybenefit of U.S. patent application Ser. No. 11/302,418 filed Dec. 12,2005, now U.S. Pat. No. 7,221,287, which is a continuation-in-part andclaims the priority benefit of U.S. patent application Ser. No.11/253,301 filed Oct. 17, 2005, now U.S. Pat. No. 7,161,497, which is adivisional and claims the priority benefit of U.S. patent applicationSer. No. 10/379,967, filed Mar. 5, 2003, now U.S. Pat. No. 6,989,765,which claims the priority benefit of U.S. provisional patent applicationNo. 60/362,155 filed Mar. 5, 2002; U.S. patent application Ser. No.11/302,418 also claims the priority benefit of the following U.S.provisional patent applications: U.S. provisional patent application No.60/634,951 filed Dec. 10, 2004, U.S. provisional patent application No.60/658,312 filed Mar. 3, 2005, and U.S. provisional patent applicationNo. 60/694,742 filed Jun. 28, 2005. The disclosure of all these commonlyowned applications is incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention generally relates to systems for monitoring motor vehicletraffic conditions on highways and incidents affecting transit, and toan improved system for alerting drivers of traffic incidents andcongestion pertaining to their usual or current route of travel, as wellas users of transit of conditions affecting them.

2. Description of the Related Art

Traffic congestion on highways and other roadways has increasinglybecome a problem, particularly in most large metropolitan areas. Forexample, traffic congestion is not without an economic impact. Forinstance, a recent mobility study by the Texas Transportation Instituteestimated that the cost of congestion for an average driver in the SanFrancisco Bay Area during 2002 was about $800 per driver per year, wheredrivers also wasted an average of 92 hours. This report also estimatedthat in general more than half of the travel delay is due to incidentssuch as accidents, obstructions, disabled vehicles, and relatedproblems.

Further, it is largely acknowledged that travelers in the US and othercountries are poorly informed of incidents and congestion impactingtheir route. According to Research Report PRR-2000-07 of University ofCalifornia in Berkeley, which was commissioned to study an incidentreporting system, radio reports are the primary source of Informationfor travelers. Radio reports are often delayed, as many radio stationsreport traffic every 10 to 20 minutes. As radio reports are limited toannouncing a few incidents and are provided for a large area, theirrelevance to an individual traveler is generally limited.

For various stages of traffic reporting on the radio, human processingand interpretation of the data is required. As congestion and trafficdensity increase, and as an increasing number of traffic monitoringsystems are being developed, traffic and transit data are becomingricher and more complex. There is also an increased need for speedydispatch of the data. As such, human processing of the data is becomingineffective, and automated processing and understanding of traffic datadesirable.

TrafficWarn™, dispatches traffic alerts to subscribers. Subscribers arerequired to choose routes for receiving alerts. Once a route is chosen,alerts are received for the entire length of the route, which can resultin the receipt of unwanted and confusing information.

The Sigalert™ system dispatches traffic alerts to subscribers.Subscribers are permitted to select portions of highways.

Although the prior art methods are designed to provide notice totravelers of important information, they generally fail to provide asatisfactory solution to the problem of informing a large population ofthe travelers as soon as, and every time a problem is known.

Typically, prior art systems for publishing traveler information do notqualify data and therefore routinely publish outdated information. Inaddition, prior art systems typically publish the exact list ofinformation from a data source without providing necessary additions orcorrecting omissions. For example, such systems do not predict orpublish an expected end time if such data is not explicitly available.In addition, some prior art systems will continue to publish potentiallyoutdated information, if for some reason the supply of fresh data isdisrupted. Experience in the development of the invention disclosedherein has shown that disruptions in data can occur frequently. Thus,prior art systems are not enabled to determine whether the impact of anincident has expired.

Therefore, a need exists to provide an improved, more efficient and moreautomated system for management of incident and congestion data.Preferably, the system should be capable of matching to active orpassive subscribers, and providing information through variousmechanisms and on various devices including cell-phones and othersimilar devices which may be ported from one vehicle to another. Thesystem should provide data that is reliable, complete, timely, andpreferably concisely stated.

The foregoing and other problems are overcome by methods and apparatusin accordance with embodiments of this invention.

SUMMARY OF THE INVENTION

A system for predicting a travel time for a traffic route is disclosed.The system includes a data source, the data being associated withvarious road segments that make up a portion of a traffic route. Thesystem further includes a forecast engine, which determines a predictedtravel time for each of the aforementioned road segments based on atleast the data for each of the road segments. The system also includes apublishing engine. The publishing engine may be configured to publish apredicted travel time for the traffic route, the predicted travel timeincluding a total travel time for each of the road segments that make upthe traffic route.

In some embodiments of the present invention, the data associated withthe road segments may be traffic speed data, which may further bereal-time speed data. Traffic speed data, in some embodiments of thepresent invention, may further include data concerning a non-trafficevent that influences traffic speed for at least one of the roadsegments making up the traffic route. Speed data associated with each ofthe road segments may be further associated with a particular timeinterval for each of the road segments. The forecast engine may, in someembodiments, be configured to determine a predicted travel time for eachof the plurality of road segments based on at least the traffic speeddata for each of the road segments in conjunction with a particular timeinterval. In some embodiments, a traveler data processor may be a partof the system such that it associates traffic speed data with each ofthe road segments in conjunction with a particular time interval.

In some embodiments, a particular time interval for a traffic route maybe associated with a particular day of the week. In other embodiments,the particular travel time interval may be associated with a series ofdays. In some embodiments of the present invention, the particular timeinterval may include an expected time at which a traveler will reacheach of the plurality of road segments. In further embodiments, theparticular time interval for a traffic route may be further associatedwith a particular time of day.

Some embodiments of the present invention may provide for the predictedtravel time for the particular time interval to be published as agraphical representation of predicted travel time versus departure time.A particular time interval, in some embodiments, may be an entireduration of a trip utilizing a traffic route.

The predicted travel time for the plurality of road segments, in someembodiments of the present invention, may include a default valuederived from the predicted travel time of one or more road segmentssurrounding one or more of the road segments. The publishing engine, insome embodiments, may be configured to publish a recommended departuretime based on one or more travel patterns identified in a graphicalrepresentation. The recommended departure time may be identified basedon at least a point of maximum slope in the graphical representation.

In some embodiments, the traveler data processor may be configured tocombine real-time traffic speed data with historical speed data. Theprocessor may be configured to update the historical speed data for theroad segments, one of which may be associated with a particular timeinterval, based on the combined traffic speed data.

The present invention also provides for a method for predicting a traveltime for a traffic route. The method includes the steps of identifyingone or more road segments making up the traffic route; identifying apredicted travel time for each of the one or more road segments, thepredicted travel time being based on at least data for each of the roadsegments; and calculating a total travel time for the traffic route, thetotal travel time including the predicted travel time for each of theone or more road segments. The data utilized by this method may includetraffic speed data.

In some embodiments of the presently disclosed method, the predictedtravel time for each of the one or more road segments may be furtherassociated with a particular time interval, the predicted travel timefor each of the one or more road segments may be based on at leasttraffic speed data for each of the one or more road segments inconjunction with a particular time interval. The particular timeinterval may include an expected time at which a traveler will reacheach of the one or more road segments. The total travel time for thetraffic route may be published as a graphical representation of traveltime versus departure time. The method may further determine arecommended departure time based on one or more travel patternsidentified in the published graphical representation, the recommendeddeparture time having been identified based on a point of a maximumslope in the graphical representation.

The present invention further provides for a computer-readable mediumhaving embodied thereon at least one program. When executed by aprocessor, the program may perform a method for predicting a travel timefor a traffic route. This method may include identifying one or moreroad segments making up the traffic route; identifying a predictedtravel time for each of the one or more road segments, wherein thepredicted travel time is based on at least traffic speed data for eachof the one or more road segments; and calculating a total travel timefor the traffic route, the total travel time comprising the predictedtravel time for each of the one or more road segments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating the overall system forcollecting, publishing and dispatching traveler information;

FIG. 2 is a flow chart illustrating the details of the processing oftraveler information;

FIG. 3 is a flow chart illustrating the dispatch of traveler informationto subscribers;

FIG. 4 is a pictorial illustration of the operation of the presentinvention in publishing and disseminating traveler information;

FIG. 5 is a flow chart illustrating an exemplary process of publishingtraveler data;

FIG. 6 is a flow chart illustrating an exemplary process of computingtravel time;

FIG. 7 is a pictorial illustration of an exemplary routing computationreport interface;

FIGS. 8A-C are pictorial illustrations of an exemplary route creationinterface;

FIG. 9A illustrates an exemplary selected route interface;

FIG. 9B illustrates an exemplary fasted route interface;

FIG. 10A illustrates an exemplary interface for generating a trafficalert;

FIG. 10 B illustrates an exemplary mobile device having received anexemplary SMS traffic alert;

FIG. 11A illustrates an exemplary animated road traffic report;

FIG. 11B illustrates exemplary three-dimensional representations ofvehicles as may be implemented in the road traffic report for FIG. 11A;

FIG. 12 is an exemplary graphic interface highlighting a significantincident;

FIG. 13 is a flow chart illustrating an exemplary process of preparing atravel time forecast;

FIG. 14 illustrates an exemplary travel time forecast.

DETAILED DESCRIPTION OF THE INVENTION

Disclosed herein are methods and apparatus for providing informationrelevant to a person traveling a specific route, at a specific time. Inthe preferred embodiment, this invention provides vehicular trafficcongestion information to subscribers, or users, through variouscommunication systems available to consumers. Although disclosed hereinas a system for providing vehicular traffic congestion information, themethods and apparatus disclosed may be used to provide any type ofinformation to users where time sensitive general interest informationis needed. Examples of such information include, without limitation,weather information, information regarding arrival and/or departure ofscheduled flights, trains, as well as other similar types ofinformation.

The disclosure herein describes preferred embodiments in terms of avehicular traffic monitoring system for the San Francisco Bay area. Itshould be recognized that the embodiment disclosed is but oneembodiment, and the invention herein is not limited to this oneembodiment. For example, the teachings herein may be used in other urbanand/or rural areas.

The invention herein makes use of various existing technologies. Forexample, information can be collected by the system from locations onthe Internet, such as from a web page that provides real time data.Users may be provided information on communication devices, such as,without limitation, a cell phone, a pager, or through email. One skilledin the art will recognize that the invention disclosed herein is notlimited by the communications technologies discussed or related to theteachings herein. As used herein, “real-time data” means data that isavailable as soon as practicable. Availability of real time data mayrange anywhere from a few seconds to a few minutes, but typically nomore than a few minutes, from the time the data was first known orpublished.

Tools for the development of software used in this invention may includetools having the capabilities of packages such as: GNUEmacs editor oneither a UNIX or Windows platform as well as Microsoft Visual Studio.NET on the Windows platform. The preferred programming languages are C,C++, C#, Perl and SQL, but other language or development tools may beused as well.

A personalized information dissemination system as disclosed hereingenerally includes components as described in this Overview. However,certain refinements and exceptions to the above relationships andfunctions exist or may be realized. These refinements and exceptions areeither disclosed herein, or may be apparent to one skilled in the art.Therefore, the invention disclosed herein is not to be limited by theexemplary embodiment, or this overview.

Referring to FIG. 1, the Traveler Information Dissemination System(TIDS) 10 includes certain components, which generally function asoutlined in this overview. Traffic data is provided by sources in realtime, or near real time, by third parties. As the data is published, thedata is collected by Feeding Programs 114. The Feeding Programs 114collect the data in various forms from a variety of Data Sources 100.The Feeding Programs 114 standardize the data, and provide the data tothe Traveler Data Processor (TDP) 150. The TDP 150 engages in variousroutines to organize and otherwise manage the data. The Traveler DataPublisher 170 and the Traveler Data Dispatcher 180 complete timelyissuance of data to subscribers, also referred to herein as “users.”Each user, having entered information desired for a specific or routineitinerary through a Commute Route Selector 190, receives the datathrough a mechanism such as a cellular phone or pager 195.

In another embodiment, traveler information is generally available forviewing, such as at a computer connected to the Internet. In thisembodiment, icons, or graphical icons are used to provide users withgeneral traveler information. In this embodiment, a user may thereforeview traveler information that may be related or unrelated to a givenroute.

Referring to FIG. 1, the Traveler Information Dissemination System(TIDS) 10 includes multiple Data Sources 100, as shown. Data may comefrom a variety of sources, and in a variety of forms. For example, inthe San Francisco Bay area, Data Sources 100 include: the TravInfo™system 104 (a collaboration of public agencies including the CaliforniaHighway Patrol, Metropolitan Transportation Commission and CALTRANS).Data may come from a web service 102. Another example of a data source100 is the California Highway Patrol (CHP) World Wide Web server 106.Other exemplary data sources include the National Weather Service 107,the PeMS system at the University of Berkeley 108, Public Event Listings113, as well as data input manually by system operators or users using,for example, a User Input Mechanism 112. Other data sources 110 may beincorporated as they become available. The User Input Mechanism 112 maybe accessible to selected operators, users, or the general public may bepermitted to provide input.

Some of these exemplary Data Sources 100, may require subscription orauthentication for access, and may be accessible via Telnet, FTP, or webservices protocols. Some of these Data Sources 100 provide comprehensivedata, while others do not. Exemplary data is now provided. Otherexamples of data appear elsewhere in this disclosure.

Example Incident Data (CHP Server)

No. Time Type Location Area 0194 3:27 AM Disabled Vehicle SB US101Redwood City JNO MARSH RD ADDITIONAL DETAILS 3:28 AM - UNK VEH ON RHSRESPONDING OFFICERS STATUS 3:32 AM - CHP Unit Assigned

Example Congestion data (CALTRANS)

Sensor ID Time Read Speed Congestion 2219 03:34:03 AM 47 2

It should be apparent that the input data inevitably contains differingcontent. For example, one Data Source 100 may report a location in termsof a street address, another Data Source 100 may report the sameincident, having the location in terms of an equipment identificationnumber, such as a sensor, while another Data Source 100 may reportlocation in geographic terms, such as latitude and longitude. Therefore,standardization of data as the data is collected is required to ensureintegrity of the TIDS 10.

Referring also to FIG. 1, the Traveler Information Dissemination System(TIDS) 10 includes one or more Feeding Programs 114. The FeedingPrograms 114 may be Data Transfer Programs 116, or Data Feeding andRepackaging Programs 118. The Feeding Program Subsystem 114 isresponsible for fetching the data from the different Data Sources 100,converting the data to a common format, and pushing the data to a serverusing periodic FTP connections, which are widely accepted by commercialservers and pose minimal security concerns. Other communication methodsmay be used.

Various Data Sources 100 provide data, some of which may requiremodification before use. Modification may involve processing to producedesired information, such as to assign a unique ID to an incident. Incases where little or no data modification is required, a Data TransferProgram 116 is used. In cases where data modification is required, aData Feeding and Repackaging Program 118 is used. A Data Feeding andRepackaging Program 118 is typically required for public data, such asthe California Highway Patrol (CHP) World Wide Web server. In thisexample, the Data Feeding and Repackaging Program 118 retrieves andanalyzes HTML data.

Examples of data that require few manipulations include data produced bya Telnet Server 104, an example being the TravInfo™ system 104. Anotherexample of data that may require few manipulations may be dataoriginating at a specific Web Service 102.

Reliability for the Feeding Program Subsystem 114 is achieved byredundancy. That is, several computers equipped with the same feedingtasks can operate in various locations and on different networks to feedsimultaneously.

The Feeding Program Subsystem 114 operation requires minimal bandwidthfor transmitting the data. This is due to the limited amount of datainvolved in each transmission, such as a list of incidents, trafficspeed and congestion information at specific locations.

The Feeding Program Subsystem 114 may thus successfully operate from asmall collection of PCs connected with a low-grade connection to theInternet, such as cable or DSL.

A Unique identification is produced for each incident, so that severalindependent instances of Feeding Programs 114 may be executed inparallel. The Feeding Programs 114 may be executed on one or morecomputers, at one or more locations. The creation of the Unique ID inassociation with each record of data provides for subsequent sorting andelimination of redundant data. The Unique ID may be created using anyconvention that is suitable to the TIDS 10 operator, (such as bycombining date, time and location information), or the Unique ID may beproduced by one or more of the Data Sources 100.

Referring also to FIG. 1, a Traveler Data Processor 150 and a TravelerData Publisher 170 typically execute on a server computer that hasaccess to large bandwidth on the Internet, and are directed topublishing data very quickly and for a large number of users. Suchservers may be potentially shared by several companies, and may imposecertain communications restrictions, for reasons such as efficiency andsecurity. Accordingly, in preferred embodiments, the Feeding Programs114 push data to the Traveler Data Processor 150. However, in someembodiments, the Traveler Data Processor 150 and/or Traveler DataPublisher 170 may obtain data directly. For example, data may beobtained directly when using the FTP protocol, or when receiving inputfrom users via a User Input Mechanism 112.

As disclosed herein, it is generally preferred that the Feeding Programs114 “push” data to the Traveler Data Processor 150. That is, the FeedingPrograms 114 send data files to the processing system: The appropriatedata processor subsequently opens the data files for processing. Inother embodiments, tasks related to the communication of data betweenthe data processors, such as, in non-limiting examples, some of theother embodiments described in the previous paragraph.

The Traveler Data Processor 150 coordinates with external resources asappropriate to ensure accurate or reliable operation. For example, theTIDS 10 maintains an accurate Clock 134 by reference to an externalclock, such as one maintained by the National Institute of StandardsTechnologies. Maintaining an Independent Clock 134 limits inaccuraciesin calculation of end times that may arise from reliance upon serverclock time.

The Traveler Data Processor 150 includes at least one and preferablymore of the following sub-processors: a Traffic Incident Processor 152;a Traffic Congestion and Speed Processor 154; a Transit Processor 156; aWeather Processor 158; and, a Public Event Processor 160. In otherembodiments, additional or other sub-processors may be included. Theseadditional or other sub-processors may be used to process data fromsources not disclosed herein.

The Traveler Data Processor 150 executes on a regular basis using eitheran on-going daemon program that switches periodically between a waitingand an active state, or a program that stops completely and is startedor executed periodically. An example of the latter is the cron mechanismon UNIX operating systems.

It is preferred to have a Traveler Data Processor 150 executefrequently, such as every minute, or more frequently. However, in someembodiments, it is appropriate to vary the interval of execution. Forexample, in the embodiment where weather information is of principalinterest, it may be necessary to execute the Traveler Data Processor 150only once per hour. Execution frequency of the Traveler Data Processor150 therefore depends on various factors, such as the nature of the datapredominating in the TIDS 10.

Although the Traffic Incident Processor 152 will now be discussed indetail, it should be realized that aspects of the Traffic IncidentProcessor 152 may appropriately function or coincide with othersub-processors, such as those disclosed herein, or as may be used inaccordance with the teachings herein. Each of the sub-processors ensuredata quality through functions including, and not limited to, completingmissing information in records of input data provided by the FeedingPrograms 114, or directly by one of the Data Sources 100. Thesub-processors therefore share and complete analogous tasks for each oftheir respective streams of data.

That is, some of the current data provided by a Data Source 100 may notbe provided with information that is important to a traveler.Accordingly, each sub-processor will analyze each record of theparticular data, or stream of data, calculate or estimate appropriatevalues as may be missing or otherwise valuable to a traveler, andinclude these values in the current or input data.

As used herein, the process of including omitted or otherwise valuableinformation in the current or input data is also referred to as“completing”, “ensuring”, or “producing” quality data. The result isthat current data, or streams of data, are transformed into qualitydata. It should be noted, however, that quality data may be referred toby other terms, such as, “traveler information” or in other similarterms, and that such data is therefore not limited by the terminology.

Non-limiting examples of ensuring data quality include: addinggeographic coordinates; including a severity level; assigning a uniqueidentifier, and others. Another non-limiting example of ensuring dataquality involves projecting an incident end time for the current data.

The Traffic Incident Processor 152 accepts input from a variety ofsources, either through the Feeding Programs 114, such as the TransferPrograms 116, the Data Feeding and Repackaging Programs 118, and/ordirectly from the Data Sources 100. Among other things, the TrafficIncident Processor 152 determines if the incidents input are currentlyactive. For example, the Traffic Incident Processor 152 determines if anincident has a current impact on travelers depending upon the incidentdescription, location, and estimated beginning and end time. As anotherexample, the Traffic Incident Processor 152 evaluates a temporal aspectof the incident. In this case, the Traffic Incident Processor 152compares the time between the beginning and end time (if presented inthe data) to the present time. If the end time is not in the past, thetemporal comparison shows the incident has a current impact. If theincident has a current impact, the incident is put into the ActiveTraveler Information Database 130.

Subsequently, incident data may be repackaged in the form below, or in asimilar form. In preferred embodiments, the incident data recordincludes a unique ID as a 6-digit number, or other unique form.

Example Repackaged Incident Data

Traffic Incident: #130194 Type: Obstruction Subtype: Disabled VehicleStarted: FRI Feb. 21, 2003 03:27:00AM Updated: FRI Feb. 21, 200303:28:00AM Expected End: FRI Feb. 21, 2003 03:47:00AM Reported By: CHPTime: FRI Feb. 21, 2003 03:28:00AM Location:On: US-101 S At: MARSH RDCity: Redwood City County: SAN MATEO

Description: .CHP 0194, 3:28AM—unk veh on rhs 3:32AM—CHP unit assigned

In the foregoing example, the expected end of the incident is computedby the system, by adding a fixed amount of time to the incident starttime or end time. The fixed amount of time added may vary, dependingupon factors such as the type and severity of the incident, and thenumber of updates an incident has received.

After the Traffic Incident Processor 152 finishes one run of execution,global positioning coordinate and severity level information ispreferably generated. Generation of this information for each incidentprovides at least for placement on a map, and ranking with respect toseverity:

Example Generated Global Positioning Coordinate and Severity Level

Coordinates: Lat: 372834N Lon: 1221004W Severity: 11

The following Table 1 lists exemplary severity levels that may beassociated with incidents when examining the type, subtype, anddescription of incidents, wherein the lowest severity number correspondsto the most severe incidents types.

TABLE 1 Severity Keyword(s) Level SIGALERT/Avoid the Area 5 InjuryAccident/Ambulance 7 Responding Accident/Traffic Collision 8 Fire 9Obstruction 10 Disabled Vehicle/Bus or 11 Truck Fog 12 Snow 13 Wind 14Closure 15 General Warning 16 Planned Event 17 Pedestrian or animal on26 roadway

Other factors, such as the incident duration may yield a lower severitynumber, as well as the indication that the same incident was reportedand corroborated by another independent data source (such as CHP 106 andTravInfo™ 104, or CHP 106 and a Web user 112). Typically every time thesystem receives an update for the same incident, indicating that thesame incident perdures, the severity number is decreased by one for thatincident. This rule may not be applied for certain types of incident,such as road work or weather-related incidents (heavy winds, snow).Severity level is therefore a preferred embodiment of indicating animpact upon a traveler. The impact is assessed by severity, or themagnitude of the disturbance typically associated with such an event.

The New Traveler Information Database 132 is used as a data resource forpushing new traveler information to users, and will be described ingreater detail in reference to the Traveler Data Dispatcher 180. TheActive Traveler Information Database 130 contains information ofincidents and other traveler data that is currently in effect andpresumably impacts travelers.

An impact determination depends, at least in part, upon time indicatedby the Independent Clock 134. That is, the end time of an incidentshould not be significantly prior to the indicated time on the Clock134. Other factors may play a role in the determination of whethertraveler information is active. For example, an incident may be reportedfor a location that is outside the geographical coverage of the system.

The Traffic Incident Processor 152 ensures that the information in theActive Traveler Information Database 130 is up-to-date; this means thatthe contents of the Active Traveler Information Database 130 containquality data for publication by the Traveler Data Publisher 170.

The Traveler Data Dispatcher 180 ensures that the New TravelerInformation Database 132 is up-to-date, meaning that the contents of theNew Traveler Information Database 132 contain quality data for dispatchto subscribers. After the Traffic Incident Processor 152 finishesprocessing an incident and incorporates associated information into theActive Traveler Information Database 130 the complete informationregarding the incident would typically be as follows:

Traffic Incident: #130194 Type: Obstruction Subtype: Disabled VehicleStarted: FRI Feb. 21, 2003 03:27:00AM Updated: FRI Feb. 21, 200303:28:00AM Expected End: FRI Feb. 21, 2003 03:47:00AM Reported By: CHPTime: FRI Feb. 21, 2003 03:28:00AM Location: On: US-101 S At: MARSH RDCity: Redwood City County: SAN MATEO Coordinates: Lat: 372834N Lon:1221004W

Advice: Drive carefullyStatus: unknown vehicle on right-hand-sideDescription: .CHP 0194, 3:28AM—unk veh on rhs 3:22 AM—CHP unit assigned

Severity: 11

The Traffic Incident Processor 152 combines incident information withthe Independent Clock 134 and other domain knowledge information tomanage, add to, enhance and correct the information. Below is an exampleof data correction, wherein the data source inputs erroneous informationfor the location of an incident: a latitude of 0 and a longitude of 0.

Traffic Incident: #26402 Type: Planned Event Subtype: Skating Started:SAT Feb. 22, 2003 07:16:30PM Updated:SAT Feb. 22, 2003 09:44:51PMExpected End: SAT Feb. 22, 2003 10:14:51PM Reported: By: CHP Time: SATFeb. 22, 2003 10:14:51PM Location: On: COW PALACE At:

City: (unknown) County: SAN MATEO

Coordinates: Lat: 000000N Lon: 0000000E Status: All Lanes Open

Advice: drive carefullyDescription: TIC: Special event—Skating: Disney On Ice at the Cow Palaceshow starts at 7:30 pm and ends at 10 pm. Expect delays

In preferred embodiments, the Traffic Incident Processor 152 detectsthat the latitude and longitude are erroneous and determines the properlatitude and longitude for the incident location:

Traffic Incident: #126402 Type: Planned Event Subtype: Skating Started:SAT Feb. 22, 2003 07:16:30PM Updated:SAT Feb. 22, 2003 09:44:51PMExpected End: SAT 02/22/03 10:14:51PM Reported: By: CHP Time: SAT Feb.22, 2003 10:14:51PM Location: On: COW PALACE At:

City: (unknown) County: SAN MATEOAdvice: drive carefully

Coordinates: Lat: 374227N Lon: 1222510W

Status: all lanes openDescription: .TIC Special event Skating: Disney On Ice at the Cow Palaceshow starts at 7:30 pm and ends at 10 pm. Expect delays

The Traffic Congestion and Speed Processor 154 typically operatessimilarly to the Traffic Incident Processor 152. Due to the nature ofcongestion and speed data, the Traffic Congestion and Speed Processor154 may execute less frequently, that the Traffic Incident Processor152. As congestion and/or speed data is considered somewhat erratic, orinconsistent, in preferred embodiments, the Traffic Congestion and SpeedProcessor 154 averages incoming data and applies filters to smooth thedata and provide reliable information. A convenient filter for thispurpose is a median filter, wherein s_(t), the speed at time t isobtained using the formula: s_(t)=median(s_(i)) wherein s_(i) are thespeed values at times before and after t. In some embodiments, the useof data averaging or smoothing causes a slight delay. Accordingly, othersmoothing algorithms or techniques may be employed to optimize theavailability or other aspects of the data.

The Weather Processor 158 examines weather data. If the data is new anddifferent from the weather data already stored in the Active TravelerInformation Database 130, then the Weather Processor 158 places the newdata in the Active Traveler Information Database 130 for the TravelerData Publisher 170 to use. The Weather Processor 158 then scans inputdata for relevant keywords, such as the names of counties. The WeatherProcessor 158 may then create hyperlinks for those such that when a Webuser on the Internet selects such a hyperlink the Web user isimmediately presented with the weather data for that county. Suchhyperlinks are preferably stored in an html file suitable forpublication.

The Transit Processor 156 and Public Events Processor 160 also operatein a manner similar to the Traffic Incident Processor 152 and theTraffic Congestion and Speed processor 154. For example, the TransitProcessor 156 and Public Events Processor 160 also adapt the frequencyof execution to aspects of the incoming data. Typically, the mostfrequent execution is needed for the Traffic Incident Processor 152,because data relating to events, such as accidents or other trafficdisruptions, typically have a short lifespan and must be disseminated asquickly as possible to be valuable or relevant to a user. In addition,it has been found that weather data, public event data, and othersimilar types of data are generally provided by at least one data source100, and therefore may, in some instances, appear in other data streams.For example, notice of a public event may be included in data from atraffic incident data source, and thus treated by the Traffic IncidentProcessor 152 as if the public event were an accident or other trafficdisruption.

The Traveler Data Publisher 170 is mainly responsible for publishing thequality data on the Internet, thereby making the data accessible to thegeneral public, including potentially users of cell-phones who canaccess websites using the WAP protocol. The TIDS 10 also include aTraveler Data Dispatcher 180, which sends or pushes quality data to auser.

The main difference between the Traveler Data Publisher 170 and theTraveler Data Dispatcher 180 is that the Traveler Data Dispatcher 180typically pushes new data to subscribers as soon as the information isknown by the system, whereas the Traveler Data Publisher 170 publishesthe data for users to actively retrieve it. Retrieval may beaccomplished, for instance, with a web browser. The Traveler DataPublisher 170 typically uses the Active Traveler Information Database130 and publishes its content, while the Traveler Data Dispatcher 180uses the New Traveler Information Database 132, so that only newinformation is being pushed to a subscriber. The New TravelerInformation Database 132 is then flushed upon each execution of theTraveler Data Dispatcher 180.

The Traveler Data Publisher 170 typically comprises a Text Publisher172, an HTML Publisher 174, and a Map Drawer 176.

The Text Publisher 172 typically publishes incident data in completetext form, which may be most appropriate for some individuals, such astransportation or media professionals interested in obtaining all theavailable detail. The Text Publisher 172 preferably sorts the incidentsin decreasing rank of the severity number. The Text Publisher 172preferably groups incidents by counties.

The HTML Publisher 174 preferably sorts incidents in decreasing rank ofthe severity number and groups incidents by counties similarly to theText Publisher 172. The HTML Publisher 174 also displays a differenticon for each incident type or subtype. The HTML Publisher 174preferably tests for the presence of keywords to determine which iconpreferably represents an incident. If no keyword is found, an icon maybe used instead.

A portion of html and javascript code may be used to implement a routinewherein when pointing to an icon, detailed information about theunderlying incident or event is displayed on the user's computer screen.An input mechanism may include, without limitation, a mouse or a stylus.

Although disclosed herein as an HTML Publisher 174, it is recognizedthat some equivalent embodiments may not employ HTML. Therefore, theHTML Publisher 174 may also be referred to as a “graphical iconpublisher.” Other aspects of publication are disclosed below.

The Map Drawer 176 displays a map with incident, speed and congestiondata, wherein at least one of the size and the color of overlying iconsused to provide notice of traveler information is varied with an aspectof the associated traveler information. For example, in one embodiment,larger overlying icons are presented for indicating more severeincidents. In other embodiments, a more intense and saturated color isused for more severe incidents.

In another embodiment, graphical icons are drawn on the map. In thisembodiment, the graphical icons may convey information themselves. Forexample, a graphical icon may include a symbol for a tow truck, anevent, a fire truck, or another symbol that is readily understood by theuser. A key to graphical icon symbology may be included or otherwiseavailable the user. An example of graphical icons, with an accompanyingkey, is provided in FIG. 4.

Preferably, the icons appear in inverse order of severity: most severe(and larger) first followed the least severe (smaller). In this way, ifoverlap occurs, the smaller icons only partially obscure the larger onesand both are visible. Other embodiments of these teachings may be used.

Similarly with the HTML Publisher 174, when the user's mouse goes overan incident icon, detailed information about the incident is displayedon the user's computer screen. In case of overlap, the most severeinformation is displayed. This is achieved by listing the most severeinformation first in the list of pop-ups.

The Traveler Data Dispatcher 180 dispatches new information tosubscriber devices, such as, in non-limiting examples, cell phones,pagers or email 195. The Traveler Data Dispatcher 180 typicallycomprises a Matcher to Segments 182, a Matcher to Severity and Time 184,an Abbreviation Engine 186 and a Transmitter SMTP/SMS/MMS 188.

An incident may be dispatched as appropriate to a given subscriber bythe Matcher to Severity and Time 184 respecting the. subscriber andgeneral requirements in terms of the incident severity.

In preferred embodiments, the Commute Route Selector 190 is accessiblefrom the Internet. Users can choose to watch specific routes at certaintimes and on certain days. The user selecting a route is preferablypresented with a selection of roadway or highway options withcorresponding visual icons representing highway signs.

For purposes of illustration of route selection, a limited sample ofroadways for the San Francisco Bay Area is presented:

US-101 N I-80 N I-880 N CA-85 N CENTRAL_EXPY US-101 S I-80 S I-880 SCA-85 S OTHER

In preferred embodiments, typically about 50 highways (hence 100directions) are presented to the user on one page next to representativeicons. The user is expected to choose one. If the user wishes to watchanother highway, then the user may select the “OTHER” highway.

The user is then requested to choose a specific roadway, a time span forwatching the specific roadway, and a level of information severity forwhich they wish to subscribe. As an example, a user may select criteriathat equate to the following:

TUE BETWEEN 2:00 PM AND 6:00 PM DOES NOT INCLUDE GENERAL WARNINGS,SLOWDOWNS AND ROAD WORK

In preferred embodiments, the foregoing selection is made using acombination of checkboxes, selection boxes and text forms. If the“OTHER” highway was selected before, then the user is requested to typein the name of a roadway in a text box.

Finally, the user is requested to choose segments along the route of hischoosing, by either selecting segments individually or selected abeginning and end segment and requesting that all segments in between beselected. Segments are typically represented to the user as follows:

On US-101 N From UNIVERSITY AVE To WILLOW RD In SANTA CLARA countyOn US-101 N From WILLOW RD To MARSH RD In SAN MATEO countyOn US-101 N From MARSH RD To WOODSIDE RD In SAN MATEO countyOn US-101 N From WOODSIDE RD To WHIPPLE AVE In SAN MATEO countyOn US-101 N From WHIPPLE AVE To REDWOOD SHORES PKY In SAN MATEO county

It is noted that internally to the TIDS 10, each segment contains aunique location or identification code. The segment information may alsoinclude latitude and longitude values. The unique location code andgeographic coordinates are preferably not revealed to the user.

The unique location code, or segment ID as referred to herein, isgenerally used for sorting and accessing data internally. That is,location information is typically stored according to a segment ID, aswell as the user criteria for desired notifications. Unique locationcodes may also be referred to as “user criteria location codes” as thesecodes are preferably used for sorting and/or other functions related tomanagement of the traveler information.

The unique location codes, or segment IDs, are known for each segment ofroad, or may be assigned for locations newly introduced to the system10. Information corresponding to a unique location code (i.e. newlyintroduced location) may be entered manually, or derived by the system10. Derivation may include referencing to a map database, or otherdatabase. For newly introduced locations, such as subsegments, thesystem 10 preferably assigns new unique IDs automatically usingconventional methods for assigning new unique IDs. In anotherembodiment, unique IDs are added manually by a system administrator.

Once a first segment selection is completed, the user is then offered tochoose another route and follow the same steps to add more segments. TheCommute Route Selector 190 stores the information provided by the userin a User Database 142. Among other things, the Commute Route Selector190 maintains a list of Active Segments 140 that are actively watched byusers.

If a user stops watching or changes the segment that he or she iswatching, then the Commute Route Selector 190 modifies the ActiveSegment 140 accordingly. This maintenance is preferably accomplished bya Maintenance Program 192 that executes periodically when the system isleast used, such as once a day during the night. In some embodiments,the Maintenance Program 192 may also monitor the number of alerts beingsent, as well as user subscription information, and may send email tosubscribers requesting feedback, or notification that a free trialperiod will end soon, etc.

Active Segment 140 are preferably stored by referencing the ID of thesegment and the window of time the segment is being watched by asubscriber. In a first embodiment, each segment ID with at least onesubscriber watching is stored as a file on disk that can be quicklyretrieved by the operating and file system of the computer once equippedwith only a file name.

Hash-tables may be also be used in an alternate embodiment instead offiles. Hash-tables reside in main memory instead of on the hard disk. Adatabase system such as Oracle or Microsoft SQL Server or Microsoft MSDEmay be used as well.

For example, a segment ID may be 9000 for a given segment, or 1 for apublic place, where public events affecting travelers may occur. Inpractice, one operational system includes about 10,000 segmentscorrelated to San Francisco Bay Area highways and about 20 publicplaces, such as 3COM Stadium, PACBELL Park, and the SHORELINEAmphitheater.

An example of the system for correlating a highway segment ID with userswatching the segment is now provided. First, in preferred embodiments,the Segment Database 136 contains a record that describes the segment.An example of a segment record maintained in the Segment Database 136 isprovided:

9000, 37.416306,-122.085846,US-101 N,N SHORELINE BLVD,N RENGSTORFF AVE,SANTA CLARA

In this example, the first number is the segment identification number,the second and third numbers represent latitude and longitude. In thisembodiment, a corresponding data file is used to store user information.An example of the information that may be stored in file named “9000” isas follows:

MON, TUE, WED, THU, FRI Between: 5 30 PM And: 8 00 PMSendto:user1@xxx.comUser:user1 Sev:25

MON, TUE, WED Between: 7 30 AM And: 8 45 AM

Sendto:18005550000@mobile.wirelessprovidername.net User:user2 Sev:25MON, TUE, WED, THU, FRI Between: 6 30 PM And: 8 30 PMSendto:user3@yyy.zzzUser:user3 Sev:25

In this embodiment, as such as soon as traveler information is locatedon a segment, and the segment ID is known, the TIDS 10 correlates thelocation of the traveler information with the segment ID, and obtainsuser criteria from the data file named 9000. The system 10 will thenprocess notifications appropriately.

In another embodiment, the times and days may be reduced to numericalcodes. For instance each possible quarter of hour of a week may beencoded using a four-digit code using between 1 and 7 for encoding theday, 00 through 23 for encoding the hour, and 0 through 3 for encodingquarters of hours. Each possible hour may be encoded with a three-digitcode. Such codes may be combined with the segment ID to form a combinedID. Matching combined IDs for traveler information and subscribers wouldguarantee that not only the segment is being watched by the subscriberbut also at a time that matters to the subscriber.

In practice there is a trade-off between the speed and efficiency thatis required to match information to subscribers and the complexity andsize of the encoding. The current system preferably uses the embodimentwherein the matching occurs on the segment ID first and a test isapplied to determine whether an alert should be sent to the subscriberor not.

In another embodiment of the Commute Route Selector 190 maintaining alist of Active Segment 140, a user may communicate to an operator averbal or written description of his or her commute route and commutetimes and the operator may enter the times and route as a list ofsegment IDs using the previously described method. The user may alsocommunicate an origin address and time, and a destination and time, oran origin zip-code and time, and a destination zip-code and time, andconventional methods may be used to compute one or several routesbetween origin and destination.

In another embodiment of the Commute Route Selector 190 maintaining alist of Active Segment 140, a device or process may communicate a user'slocation, speed and/or heading back to the TIDS 10 through use of awireless device, such as a transmitter or a transceiver. An example of awireless device includes a Global Positioning System (GPS) receivercoupled with a cell phone.

There are means known in the art, other than GPS, to obtain positioninformation. Notably, for a cellular telephone user, the cellularcarrier may use “time difference of arrival (TDOA)” from cellular basestations for specifying the location of the cellular telephone.

The information provided by a GPS device supporting the NMEA standardwould preferably be presented as indicated in the line below, whereinthe second value is the time in hours, minutes and seconds in UTC or GMTtime, the fourth and fifth values represent latitude, the sixth andseventh longitude, the eight speed in kilometers per hour, the ninthvalue represents the heading in degrees of an angle:

$GPRMC, 221218, A, 3720.8323, N, 12203.6006, W, 90.40, 179.6, 150203,15.4, E*51

In preferred embodiments, such information is typically updated everysecond. The latitude and longitude are first converted to decimal valuesusing methods known in the art, and are then compared with the segmentlatitude and longitude values of the Segment Database 136. A segment istypically associated with one latitude and one longitude value that istypically representative of the center of the segment. A conventionalmethod for determining which segment the subscriber is on would comparethe latitude and longitude of each segment with the current latitude andlongitude, compute a Euclidean distance in decimal latitude andlongitude space, and select the closest segment according to thedistance. The problems with this conventional method is that thedirection of travel is not taken into account, as well as theinterference between segments on unrelated routes that are close inlatitude and longitude. An exemplary result of applying thisconventional method as is follows: after one second elapses the systemwrongfully determines that the subscriber has changed direction:

37.3450633333333, −122.060001666667, 99.970000, CA-85 N, W HOMESTEAD RD,W FREMONT AVE 37.3448166666667, −122.059996666667, 98.500000, CA-85 S,FREMONT AVE, HOMESTEAD RD

The correct answer, obtained using the following embodiment of thepresent invention, is as follows: the subscriber has moved to anadjacent highway segment in the subscriber's direction of travel.

10000,37.3450633333333, −122.060001666667,99.970000,12404,CA-85 S,E ELCAMINO REAL,FREMONT AVE, 1.9691579361947e-005,0.9960453130365210001,37.3448166666667, −122.059996666667,98.500000,12405,CA-85S,FREMONT AVE,HOMESTEAD RD,4.72667650033294e-006,0.985999240195501

The collection of highway segments forms a directed graph.

The TIDS 10 determines for each segment relationships with other nearbysegments. For instance, segment 10000 immediately precedes segment 10001along highway CA-85 Southbound, as Segment 10000 ends at FREMONT AVE andSegment 10001 starts at FREMONT AVE.

Using incident segment information, the TIDS 10 determines a vector in(latitude, longitude) coordinates for the segment, compute the distanceto this vector using methods known in the art for the distance between apoint and a vector and also compute a scalar product between thedirection of travel and the segment direction.

The best segment match is obtained with a combination of a low distanceand high scalar product, with a preference for the same segment on whichthe subscriber already is or the following segment along the samehighway as it is noted at 60 miles per hour, the vehicle stays on thesame segment for about 60 measurements of the GPS device. The currentformula is preferably used to determine the best match: MinimizeA*distance−B*scalar_product+C*ID_flag wherein A, B, and C are constantsthat may be tuned, and ID_flag equals zero if the segment is the sameand one if the segment is different for the current segment. For thefirst match as there is no current segment all ID_flags are equal tozero. B may be set to zero, in which case segments corresponding tonegative scalar products must be eliminated.

A wireless device may communicate with the server hosting Active Segment140 via WAP, HTTP, SMS, etc. A subscriber may thus subscribe to travelerinformation completely automatically, without action from his or herpart. The subscription uses a combination of wireless communication andgeographic positioning, informing a server of the segment on which thesubscriber is, the, segments on which the subscriber is likely to be onin the near future, and communicating this information to the CommuteRoute Selector 190 for insertion in the list of Active Segment 140.

Such data automatically transmitted to the Commute Route Selector 190may be used for recording a usual commute route.

The percentage of traveling spent commuting is significant in the US,thus the Commute Route Selector 190 provided by the present invention isparticularly beneficial to travelers that repetitively commute a knownroute. The facility provided by the Commute Route Selector 190 thereforesimplifies the process of gathering and/or retaining the commute routeinformation.

In case the user's commuting profile is already known to the system,automated transmission of the user's current segment may locate the useralong his or her commute route and provides for temporarily discardingthe segments already traveled by the user for the purpose of sendingalerts.

If the current route is not usual or if there is no particular need orwant to record the route, the information transmitted to the CommuteRoute Selector 190 may still be used to dispatch current incidents inneighboring or upcoming segments. Such information may also be used tosubscribe temporarily to alerts on upcoming segments, based upon speedand time data. A combination of publishing of current incidents(relevant for the Traveler Data Publisher 170) and temporarysubscription to dispatches (relevant for the Traveler Data Dispatcher180) may be suitable so as to limit the number of back-and-forthcommunications between the user's wireless device and Commute RouteSelector 190 and server or computer on which the Commute Route Selector190 runs.

Finally, the information collected may be used to compute travel timeand speed, as it is widely regarded that GPS data systems provideaccurate time and speed estimates. The travel time and speed, which area form of traveler information, and may be optionally published by theTraveler Data Publisher 170 and dispatched by the Traveler DataDispatcher 180 if there is an agreement with the source of the data thatsuch further publishing and dispatching are acceptable.

The level of severity of the information dispatched to the user may bechanged at any time by the subscriber or the, administrator of thesystem 10. The system 10 may monitor the number of alerts that were sentto a user, and beyond a certain number send an email to the user,explaining that various levels of severity are possible. The emailrecipient may then click on either link to adapt the level of severityof the information to his or her choosing. An exemplary email is shownbelow, explaining the current levels of severity supported by the system10. Since an underlying system of numerical severity values is used, anynumber of thresholds may be put in place corresponding to fewer severityvalues exposed to subscribers, such as a three-level system shown below.But an n-level system where n is an arbitrary integer value is alsopossible. An exemplary e-mail message follows:

Dear subscriber

You can customize the level of alerts SF By Traffic Informationdispatches to you. We currently offer three levels of alerts:

1—Incidents that cause the closure of one or several lanes, such as CHPSigalerts, serious accidents, fires.

Please follow the link below to turn on these types of alerts only.

<link address provided here.>

2—All other incidents except warnings, heavy traffic alerts, etc. Pleasefollow this link:

<link address provided here.>

3—All incidents including warnings. These may be numerous depending uponthe roads you are watching.

Please follow this link:

<link address provided here.>

You may change your options at any time using any of the links above.

It is expected that the Data Sources 100 are, or will be, available indifferent locations, on different networks, and on different computers.However, it is conceivable to have several data sources on the samecomputer.

In preferred embodiments, the Data Sources 100 may communicate with thefeeding programs 114 and the Traveler Data Processor 150 through theInternet, however, it is recognized that a large variety ofcommunication requirements or protocols may exist and need to beovercome. However, the techniques required for communicating data fromthe Data Sources 100 are not discussed further herein.

In preferred embodiments, the Traveler Data Processor 150, Traveler DataPublisher 170, Traveler Data Dispatcher 180, Commute Route Selector 190and Maintenance Program 192 execute on the same computer, such as aserver. In preferred embodiments, the Active Traveler InformationDatabase 130, New Traveler Information Database 132, Independent Clock134, Segment Database 136, sub-segment Database 138, User Database 142and Active Segment 140 are also located on the server. However, providedthese different components have functional access to all databases andother components they need to operate, they may be located and executedon different computers. An example of a system configuration that issupportive of this implementation includes, without limitation, anetwork system.

Reliability is considered to be a critical factor for a successfultraffic reporting system, as well as cost effective operation.Therefore, the invention disclosed herein was designed to achieve a highlevel of reliability without incurring prohibitive costs. The abovedescribed design choices have allowed at least one operational exampleof the invention disclosed herein to achieve significant reliability ata low cost.

The system 10 disclosed herein decouples the operations of feeding andpreprocessing the data (subsystems 114 and 150) publishing the data onthe Internet (subsystem 170) and delivering the data to subscribersusing messages (subsystem 180).

The Web/Internet hosting industry has made available computers withsignificant computational power, a large bandwidth to the Internet, andsoftware, i.e “web servers, or application servers” specificallydesigned to serve customers files or the result of executing programsthrough the Internet and Web browsers such as Netscape and. Microsoft'sInternet Explorer. Non-limiting examples of web server or applicationservers are: Apache Software Foundation's “Apache” MicrosoftCorporation's “IIS”, and BEA Systems's “WebLogic”.

Because of the requirement to serve web pages on a continuous basisschedule, the combination of hardware and software involved should bevery reliable, rarely unreachable or out of service.

Accordingly, the Traveler Data Processor 150 and Traveler Data Publisher170 use programs that may execute periodically on a server, merging thedata from different sources, and preparing the data for publishing.These programs, however, typically do not fetch the data through theInternet but rather look periodically if new data was deposited/madeavailable on the server.

The operation of the Traffic Incident Processor 152 is more clearlyexplained with reference to FIG. 2. Preferably, Traffic IncidentProcessor 152 reviews all the traffic incidents in the Active TravelerInformation Database 130 and rewrites it from scratch every time it isexecuted. Other sub-processors may similarly process corresponding inputdata.

In Step 200, the Traffic Incident Processor 152 obtains the current timefrom the Independent Clock 134 and determines an incident expirationthreshold. In one embodiment, the Traffic Incident Processor 152completes this step by subtracting a few minutes from the current time.As an example, the Traffic Incident Processor 152 subtracts about tenminutes. This embodiment subsequently provides for the publication ofincidents a few minutes after their expected end time, thus accountingfor some of the potential errors in the expected end time.

Then, available Data Sources 100 for traffic incidents are processed inturn. The first Data Source 100 is the Active Traveler InformationDatabase 130 which contains the list of incidents currently known andcurrently active. The subsequent Data Sources 100 may be processed inany order, for instance in the ordering implied in FIG. 1 inside theData Sources 100 block.

In Step 202 the next Data Source 100 is opened for reading. The datafrom the Data Source 100 is preferably located on the same computerwhere the Traffic Incident Processor 152 operates, as pushed using theFeeding Programs 114; if this is not the case there are varioustechniques for retrieving the data from a remote location, using eitherthe Telnet or FTP network transfer protocols: Remote access is notpreferred as this may incur a delay and a potential risk that the dataor network connection may be unavailable.

In Step 204, an incident is retrieved from a Data Source 100. In Step206, the system 10 reads the incident ID of the incident. Preferably thesystem 10 uses 6-digit incident IDs for an incident that is encounteredby the system 10 for the first time, for instance 123456. If the system10 receives updates on that incident then a 9-digit system is usedinstead as follows: the first update will have the ID 123456000, thesecond update 123456001, the third update 123456002 and so on.

The system 10 may thus determine if the incident newly introduced, or isan update to existing information. This determination is completed bytesting the ID. In preferred embodiments, the test ascertains if the IDis larger or equal to one million. In case the ID is larger or equal toone million, then the system 10 computes a base ID as follows: BaseID=ID/1000.

In Step 208 the system 10 processes the end time of the incident. Incase the end time is not available, a default duration is being added tothe start time of the incident. If the start time of the incident is notavailable, then the current time of the Independent Clock 134 is used.The fixed duration is dependent upon the level of reliability that isattached to the Data Source 100 and the type of incident. For instancean incident from data source CHP 106 and relating to a PEDESTRIAN ON THEROADWAY, may be assigned a default duration of 20 minutes, while anAccident reported by data source TravInfo™ 104, which may have gonethrough further verification of the data, may be assigned a defaultduration of 30 minutes. Default durations are typically determined whenmonitoring data sources and observing the incident durations reportedwhen available.

In case the end time is at a date too far remote in the future, such asmore than two days after the current time, this is assumed to be anerror in the data, except when the incident is ROAD WORK. The end timeis then corrected by combining the current date with the incident endtime.

In Step 210, if the end time predates the incident expiry date then theincident is not inserted in the Active Traveler Information Database 130and the process returns to Step 204 where the next incident is read.

Otherwise, in Step 212, the system 10 reads the incident description.Upon reading and analyzing the description of the incident, the system10 determines if the incident is a duplicate or not, meaning that thesame incident is already in the Active Traveler Information Database130. A decision is then made to erase the incident from the ActiveTraveler Information Database 130 or to erase the incident under currentconsideration.

Therefore, the system 10 evaluates whether an incident that appears tobe a duplicate is a duplicate or is an update or correction to existinginformation. The system 10 then saves the best data, and discards thelesser quality version.

In Step 212, the system 10 may also apply a number of corrections to theincident description, such as translating a number of abbreviations intoplain English text. Examples: #1 LANE is translated to FIRST LANE FROMLEFT; 3A is translated to AAA TOW REQUESTED.

In Step 214, the system 10 determines if the base ID of the incident ascomputed in Step 206 already exists in the Active Traveler InformationDatabase 130. If this is the case then the system 10 takes note of theincident currently listed in the Active Traveler Information Database130 and with an identical base ID. The system 10 then executes Step 216.Otherwise, the system 10 executes Step 220.

In Step 216 the system determines if the incident is a duplicate. Inpreferred embodiments of duplicate incident testing, the incident mustend after the existing incident, by at least 15 minutes. This testlimits the risk of a data source automatically generating an excessivenumber of corrections within a few minutes; which could result in alarge number of updates being dispatches to subscribers, with very fewchanges in the Information actually conveyed. Other aspects of theincident information may be tested as well. For example, descriptionand/or location information may be tested.

In general, tests designed with certain consideration in mind. Forexample, one consideration is that some recurring incidents may becontinuously updated with only the end time being different. Examples ofthese incidents include congestion or “heavy traffic” incidents, weatherconditions such as wind, ice, or snow. Otherwise, minor differences inthe description and location may occur as the incident is not yetcompletely known. It is suitable to wait a little before the informationis completely confirmed and republish or redispatch the incident then.

If the incident is a duplicate, the system 10 returns to Step 204 forreading of the next incident; if not the system executes Step 218.

In Step 218, the system computes a 9-digit ID from the incident ID. Ifthe incident ID already has 9-digit, then it is simply incremented byone. Otherwise if the incident ID has 6 digits, then it is multiplied by1000. The system 10 then executes Step 222.

In Step 220, the system 10 determines whether the incident descriptionalready exists for some incident currently listed in the Active TravelerInformation Database 130. If this is the case then the incidentcurrently listed is dropped from the database 130 in Step 222.

In Step 222, the incident currently listed in the Active TravelerInformation Database 130 is dropped from the database and the system 10executes next Step 224.

In Step 224, the incident is inserted into the Active TravelerInformation Database 130. In Step 224, the system 10 computes latitudeand longitude if missing or corrupted. This computation is completedusing the Segment Database 136. In testing, it was found that the methodcan locate on average 80% of the incidents with missing latitude andlongitude.

Not all data sources provide a latitude and longitude together with thedescription of an incident. In the general case, the system 10 mustinfer a latitude and longitude from the specification of theintersection of two highways.

For each incident that is not geocoded, i.e. that does not alreadycontain latitude and longitude Information, the address is decomposedinto an “inc_ON” highway and an “inc_AT” highway: for instance:

inc_ON US-101 Ninc_AT WHIPPLE AVE(where “inc_” stands for incident)

Before string comparisons are made, some typical translations between agiven data source and the Segment Database 136 are applied. Exemplarytranslations are:

BRDG becomes BRIDGEMOUNT becomes MTPZ becomes PLAZAEXWY becomes EXPYPKWY become PKYAV becomes AVE

Note that these translations are applied to isolated words only. Forexample, AVENUE is not translated to AVEENUE. In addition the followingstrings are prepared when the specification of a direction along inc_ONwas detected:

Opposing direction:inc_ON_OPP US-101 SNo direction:inc_ON_NOP US-101

If there is a match with both the inc_ON and inc_AT and one pair (ON:,AT:) for a segment in the Segment Database 136, then the incident isdetermined to be geocoded and the latitude and longitude recorded in thedatabase are used for the incident.

The match does not have to be exact: this is implemented by goingthrough the list of segments and intersections in the database andassigning a score to each potential match, while retaining the matchwith the maximum score. The scoring system works in the following order,from the maximum score to the minimum score:

14 (Unk_ON equals ON) and (unk_AT equals AT) and the specified countyfor the incident equals the county specified in the database for that(ON, AT) combination: exact match, and maximum score 13 (Unk_ON equalsON) and (unk_AT equals AT) with a different county (which is the resultof errors at typically happens at the boundary between counties) 12(Unk_ON equals AT) and (unk_AT equals ON) (inverted) 11 (Unk_ON equalsON) and (AT contains unk_AT): contains meaning that the string ATcontains completely unk_AT (for instance “CAPITOL AV” contains “CAPITOL”entirely) 10 (Unk_ON equals ON) and (unk_AT contains AT) 9 (unk_ON_OPPequals ON) and (unk_AT equals AT) 8 (unk_ON_OPP equals ON) and (ATcontains unk_AT) 7 (unk_ON_OPP equals ON) and (unk_AT contains AT) 6(unk_ON_NOD equals ON) and (unk_AT equals AT) 5 (unk_ON_NOD equals ON)and (AT contains unk_AT) 4 (unk_ON_NOD equals ON) and (unk_AT containsAT) 3 (ON contains unk_ON_NOD) and (unk_AT equals AT) (for instance ifON is US-101 S and unk_ON is US-101 N) 2 (ON contains unk_ON_NOD) and(AT contains unk_AT) 1 (ON contains unk_ON_NOD) and (unk_AT contains AT)

The scores are only indicative and may be refined or new matchingcriteria may be entered. The scoring system requires a single passthrough the database (that contains local highways only and is typicallyrather small). In another embodiment, the scores may be determined usinga distance function between two strings such as the Levenshtein Distanceknown in the art.

On average, at least 80 percent of the incidents lacking geographiccoordinates may be geocoded, and thus assigned a location on a map usingthe abovementioned process, or equivalents thereto.

In Step 226, the system 10 determines whether there are more incidentsfor the current data source being considered. If this is the case, thenthe system 10 returns to Step 204 and otherwise, the system 10 executesStep 228.

In Step 228, the system 10 determines whether there are more datasources to be considered. If this is the case, the system 10 returns toStep 202 and otherwise terminates, awaiting for a next scheduledexecution.

FIG. 3 describes aspects of the Traveler Data Dispatcher 180. TheTraveler Data Dispatcher 180 comprises a Matcher to Segments 182, aMatcher to Severity and Time 184, an Abbreviation Engine 186, and aTransmitter SMTP SMS (Short Message Service)/MMS (Multimedia MessageService) 188.

The Matcher to Segments 182 is preferably implemented with the Steps 302through 318 illustrated in FIG. 3.

The Matcher to Severity and Time 184 is preferably implemented with theSteps 320 through 324. The Abbreviation Engine 186 and transmitter 188are implemented in Step 326.

In Step 302, the next incident from the Active Traveler InformationDatabase 130 is retrieved. If there are no more incidents, the processends.

In Step 304 the system determines whether the ID of the incident alreadyexists in the traveler Information database that was previously active.(Previously active means that the incident was active and published inthe previous iteration of the system 10). If this is the case, then thesystem 10 returns to Step 302, or otherwise proceeds to Step 306.

In Step 306 the system 10 determines whether the ID exists in the listof the last few incidents. If this is the case the system 10 returns toStep 302, and otherwise executes Step 308. Preferably the last fewincidents are a list of IDs of the incidents that the system 10 has mostrecently encountered.

In Step 308, the incident is considered to be new and is inserted in theNew Traveler Information Database 132. The incident is also set to bethe first in the last few incidents list, and the last incident of thatlist is removed.

In a majority of the data sources for traveler incidents, the incidentis reported on one highway or transit route, in spatial relation to anintersection with another route or stop, such as: Before, after, at,just north of, etc.

As such, in Step 308, the Matcher to Segments 182 attempts to interpretsthe location of the incident as an (ON: AT:) pair such as: ON: I-580 EAT: GROVE WAY wherein the AT: component of the location may potentiallybe missing. Preferably, the system looks for the keywords “ON” and “AT”,but also for JUST NORTH OF, OR JNO, JUST SOUTH OF, or JSO, etc. and asmany similar ways of specifying an intersection location as possible.

The system 10 then builds a first hash-table mapping the ON: AT:location for segments of the Segment Database 136 to segment ID and wellas a second hash-table mapping the ON: END: segment location to segmentIDs. For instance, for the segment 10001,CA-85 S, FREMONT AVE, HOMESTEADRD the ON: AT: key for the first hash-table is: CA-85 S FREMONT AV andthe ON: END: key for the second hash-table is: CA-85 S HOMESTEAD RD.

Both keys are mapped to the segment ID, 10001 in the hash-tables.Preferably both hash-tables are built ahead of time, because they arethe same for all the incidents being treated and only depend upon theSegment Database 136. Step 310 is executed next.

In Step 310, an ON: AT: key is built for the incident in the samefashion as for the list of segments in Step 308. If there is an exactmatch in the first hash-table then it is determined that the incident ismatched to a segment and the system executes Step 320 next (for instanceif the ON: AT: key is CA-85 S FREMONT AV then there is an exact match inthe first hash-table and the incident is determined to be on Segment10001). Otherwise if there is an exact match with the second hash-tablethe system executes Step 320 as well.

Otherwise, in Step 312, the key is reversed, meaning that the AT: ON:key is built for the incident. If there is an exact match with the firsthash-table the system executes Step 320. Otherwise if there is an exactmatch with the second hash-table the system executes Step 320 as well.

Otherwise, in Step 314, the system 10 goes through the SubsegmentDatabase 138. A subsegment is a portion of a highway segment, that doesnot fully extend from the segment origin (or AT:) to the segmentdestination (or END:). A subsegment may simply be an intersection,wherein the (END:) information is unavailable, or even simply a place,wherein both the AT: and END: information is unavailable. But in allcases the subsegment must be associated with a reliable latitude andlongitude. Subsegments are particularly useful because incidents may bereported inside a segment as opposed to a segment endpoint. As anexample of subsegment, one segment 12345 along US-101 S is definedbetween MONTEREY RD and CA-25 and is assigned a latitude and longitudevalues of 36.973988 and −121.555046. The latitude and longitude of asegment are typically representative of the center of the segment. Oneparticular subsegment of this segment would be 60235 on US-101 S atCASTRO VALLEY RD with a latitude of 36.967833 and a longitude of−121.552667. A subsegment is typically associated with a numeric ID thatdistinguishes it from a segment, typically associated with a lowernumber ID. A subsegment is also associated with the ID of the largersegment it belongs to: 12345. A subsegment may also be created for a newspelling or denomination of an existing segment endpoint.

In Step 314, the system 10 tests the incident location as an ON: AT: keywith the subsegment Database. If an exact match is found, then Step 320is executed next, otherwise Step 316 is executed.

In Step 316, the system 10 attempts to create a new subsegmentcorresponding to the current incident, as no corresponding segment orsubsegment could be found so far.

For instance an incident may be reported on US-101 S at CASTRO VALLEY RDwith a latitude of 36.967833 and a longitude of −121.552667.

The system 10 computes the distance in (latitude, longitude) spacebetween the incident location and each road segment along the same roadof the incident (Only the road segments on US-101 S are searched in theprevious example. Searching only those types of segments is easilyperformed by matching the string in the ON: portion of the segmentdescription). The closest road segment is retained. The distance inlatitude and longitude is then approximately translated into a Euclideandistance using the following formula: 0.01 degrees of latitude orlongitude correspond to about 1 Kilometer.

If the Euclidean distance in approximate kilometers is sufficientlysmall (about one kilometer) then the incident is determined to occur ona subsegment of the segment and the incident is determined to belocalized on the segment. The system 10 then proceeds to Step 318.Otherwise the system 10 returns to Step 302 and considers the nextincident.

In Step 318, the subsegment determined in Step 316 is added to thesubSegment Database 138, and the system 10 proceeds to Step 320.

Another advantage of the above described methods for matching incidentsto segments is that in case Information is only partially available(such that the END: or even AT: and END: of an incident, the system maystill be able to find an exact match in the Segment Database,considering the missing Information as an empty string and performing amatching on the remaining, available Information. Since other parts ofthe system are dedicated to computing latitude and longitude of anincident when such latitude and longitude are unavailable, in most casesthrough Steps 310, 312, 314, and 316 incidents may be matched to asegment.

Another advantage of the present invention is that the incidentdatabases gradually increase in accuracy as more and more incidents areprocessed: subsegments are being continuously created and the matchingof incidents becomes increasingly flexible.

In Step 320, the system 10 examines the next user from the list of userssubscribed for alerts relating to the matched segment. If there is nomore user subscribed for the matched segment, the process ends.

In Step 322, if the severity of the present incident matches the levelof severity that the user has requested for the segment (specifically,if the severity number is lower, as lower numbers correspond to moresevere incidents in the present invention) the system 10 proceeds toStep 324 and otherwise the system returns to Step 320.

In Step 324 the system 10 examines the predicted window of time for theincident, and determines if there is any intersection between thepredicted window of time for the incident and the window of time theuser watches the segment for. This is preferably performed by makingcomparisons of precedence between dates. Determining whether two windowsof time overlap is analogous to determining whether two linear segmentsoverlap in one dimension, and the techniques are generally known.

If the two windows of time overlap, the system 10 proceeds to Step 326,and otherwise the system 10 returns to Step 320.

In Step 326 the system 10 prepares a message by means of compiling andespecially abbreviating the Information, and dispatches a message to theuser on the user preferred address.

In preferred embodiments, the system 10 preferably interprets anydelivery address (cellular telephone, pager, email) as an email address.The system 10 looks in a lookup database for converting a wirelessprovider name to a valid email address suffix publicized by the wirelessprovider. For instance, a wireless device may be mapped using aconvention such aswirelessdevicenumber@mobile.wirelessdeviceprovider.net in the lookupdatabase. The lookup database is compiled by collecting addressespublicized by wireless providers.

The system stores a primary and a secondary address for each user, whichmay be the same. The user may attach either the primary or the secondaryaddress to any segment that the user watches. For instance a user maywant to receive alerts on a cell phone (primary address) on her way towork in the morning, and at work on her company e-mail system (secondaryaddress) right before she takes her car to return home.

To send a text message on a cellular telephone, the message must betypically abbreviated to fit in 100 to 160 characters, depending uponthe wireless provider. The following techniques have been implemented inthe Abbreviation Engine 186 for this purpose. Abbreviation engine 186therefore provides a benefit of formatting traveler information fordissemination to systems with certain formatting requirements, as wellas a separate benefit of enhancing information transfer. That is, as auser becomes accustomed to a set of abbreviations, the user is able tomore quickly read and digest the traveler information that if thetraveler information were spelled out in long form.

Therefore, it is considered that the following embodiments of theAbbreviation Engine 186, and the terms used in association with theAbbreviation Engine 186 are not limiting and only exemplary of how anAbbreviation Engine 186, or equivalent technique, may be used inconjunction with traveler information.

At a high level, only 6 types of information are transmitted in themessage: 1) email address of sender 2) location where the problem occurs3) window of time for the incident 4) incident type and subtype 5)status of the incident 6) description of the incident (at least, thebeginning thereof).

The origin email address is necessary for the Information to be sent atall through the Internet. The smallest possible valid email address forthe business is preferably used.

The location of the incident as an intersection is obtained byjuxtaposing the two roadways participating in the intersection, with an@ sign in between. Only the first 12 characters are kept, and anytrailing space is removed. An example is provided:

E SAN MATEO BRIDGE

becomesE SAN MATEO (11 characters) and not:E SAN MATEO (12 characters)

The begin and end time, displayed for instance as: “at10:00PM til11::PM”(the days are eliminated, assuming it is today as the information isdispatched very quickly and the date may be carried elsewhere in theheader of the message by the provider).

Type and SubType of incident: a look-up table of abbreviations forsingle words is used. Examples of abbreviations and corresponding termsare provided:

maintenance is maintoperations is opsobstruction is obstructroadway is rdwayvehicle is vehinjury is inj,

Once these substitutions are done the first 15 characters are kept, andany trailing spaces are removed.

Status: a look-up table of abbreviations for single words is used.Another example is provided:

blocked is blkdcenter is ctrleft is ltright is rttwo is 2three is 3traffic is traf

Description: to determine the available character count, the number ofcharacters already used in information types 1 through 5 above issubtracted from 160, after removing codes, special symbols, andpotentially using further abbreviations. Trailing spaces are removed.

The final message may be presented as follows: I-80 W @POWELL ST at5:20PM til 5:47PM disabled veh rt lane blkd WB I-80 just after Powell St

Representing about 90 characters automatically abbreviated from fairlyextended and detailed incident information, which originated in a priorart system as the following:

<!- - - Traffic Incident: #397772 - - ->

Subtype: disabled vehicle

Started: TUE Feb. 19, 2002 05:20:00PM Updated: TUE Feb. 19, 200205:20:12PM Expected End: TUE Feb. 19, 2002 05:47:08PM Reported: By: CHPTime: TUE Feb. 19, 2002 05:47:08PM Location: On: I-80 W At: POWELL STCity: EMERYVILLE County: ALAMEDA Coordinates: Lat: 375017N Lon: 1221747W

Status: right lane blockedAdvice: drive carefullyDescription: 1705-WB I-80 just after Powell St stalled vehicle blockingthe right lane. 5131

The message is typically dispatched to its destination email via an SMTPserver, however connecting to an SMS gateway would also be possible. Awireless provider will typically operate an SMTP gateway, which willthen transmit the message to the recipient.

Preferably the message header incorporates a number of notificationrequests following the Delivery Service Notification (DSN) standard. Inthis way, the System 10 is typically notified of whether the message wasreceived, read or deleted before being read, and the time of delivery.Not all gateways respond to the DSN standard and therefore, the system10 cannot rely on receiving any or all of the notifications. Anexpiration date or time tag may also be added, indicating a time atwhich the information will stop being relevant, in case the deliverywould be late. Some e-mail clients such as Microsoft Outlook acknowledgethe expiry date.

Periodically, a program, such as the Diagnostic Program 194 is launchedto examine the proper functioning, or the health, of the system 10. Inone embodiment, the program examines the logging files. The DiagnosticProgram 194 looks at the numbers of incidents published. The DiagnosticProgram 194 determines whether there is an abnormal pattern in thenumbers and origin of incidents produced. For a given source of data thenumber of new incidents per day varies from day to day but almost nevergoes down to zero. Exemplary statistics are as follows: x

A=Total number of new incidents reported in the last hour.B=Average number of incidents reported at any given time in the pasthourC=Average number of incidents published at any given time in the pasthour: A number equal to zero would mean that the publishing side iscompletely devoid of data, which would certainly be indicative of atechnical problem.D=Variation between the number of incident reported by a data feed: somevariation is a good indicator of a healthy behavior for the data source.

As incidents become static and new incidents are just being reported,the exact number of incidents reported at a given time is necessarilysubject to some minor variations. This test compounds these variationsover a period of one hour or so.

If statistic D is high, it is very likely that the data source ishealthy. D is a positive value adding/compounding all absolute values ofthe differences between the number of incidents reported at a giventime, and the number of incidents reported in the previous iteration.

E is a positive or negative value derived from adding all thedifferences between the number of incidents reported at a given time,and the number of incidents reported in the previous iteration.

F=number of incidents currently being published.

The email address of an administrator for a given data source can berecorded.

If any test, or combination of tests indicates a problem, a simplealgorithm, such as the exemplary one below, is used to detect theproblem. An email message containing the statistics and the algorithm'sguess is dispatched to the administrator(s) as well as individualsresponsible for the data source. In addition, a message indicatingtechnical problems may be displayed on the publishing side. (The lateris reserved for situations where the number of published incidents iszero).

One example of criteria that is applied to decide whether there is aproblem on the server or not is a test that evaluates, if A is equal tozero, then check whether F is less than a minimum threshold. If this isthe case, then a preliminary determination is made that there is aproblem, (meaning, that in addition of no new incidents coming in, thecurrently published number is getting very low) or E is less than aminimum negative threshold (meaning that the pool has been decreasing insize).

If this preliminary determination is not made, then the tests stop andno email message is sent or problem reported to an administrator.

If this preliminary determination is made, then the system checkswhether B equals zero. If this is the case, then the algorithm returnsan estimation of the problem as: “probably new data cannot betransmitted to the server. Otherwise if D equals zero then the algorithmreturns: “probably new data cannot be transmitted to the server”Otherwise if F equals zero and B is greater than zero (some incidentsreported but none published) “Incidents are transmitted to the serverbut unpublishable”

Otherwise the system 10 determines that there is no significant problemafter all.

In further or other embodiments, the following criterion could be usedas well: G=Ratio between number of incidents reported and number ofincident published.

A value for G of close to one, is a good indication that the systemworks well overall. If G is low but D is high, there is an indication ofproblems on the server/publishing side. System 10 diagnostics may becompleted on a predetermined schedule, or as required.

The System 10 provides facilities for the management of the userpreferences and subscriptions. The following Table 2 lists exemplaryinformation that may be displayed by the System 10 for each user: theuser's email address; the user's first name; whether the user's emailaddress was confirmed by the user's response to an email; A potentialreferral code, whether or not the user is currently subscribed toalerts, and a potential date of subscription end.

TABLE 2 first Referral Last

this

so Select User Namef Confirmed code Subscribed visit Created Primaryaddress Secondary address month far

<link to user Alex Yes/Confir- SFBT Yes/no date date 123456789@xxx.yyyuser@zzz.ttt 15 200 profile here> mation code date <link to user profilehere>

indicates data missing or illegible when filed

A super-user of the System 10 may view and update the profile of a user.A super user may access a user profile by selecting a displayed link toa user profile displayed in Table 2. A super user may thus enter userpreferences manually in case the user would prefer or request asuper-user to do so. A super user may also subscribe and unsubscribe auser, as well as add or subtract a period of time to the subscription. Asuper-user may also compose and send an email message to one or moreusers, or compose and send a text message to one or more usercell-phones or pagers.

In a preferred interface for such super-user actions, the super-userchecks one or more check-boxes in the “select” column of Table 2, andthen activates one button of a collection of buttons labeled as follows:

“ComposeMail”, for composing an email message to one or several users“TextMessage”, for composing a text message to one or several users

“Subscribe”, “Unsubscribe”, “Add1Week”, “Sub1 Week”, “Add1Month”,

“Add6Months”, for managing the user's subscription“Confirm”, for marking a user's address as being confirmed

“MailCoupon”,

“MailConfirmationCode”, for sending account confirmation information toa user via an email message“MailCoupon”, for sending a discount coupon to a user via an emailmessage“Delete”, for deleting a user.

It is considered that these features, are only exemplary of additionalfeatures that may be available to a super user, and are therefore notlimiting of the invention herein.

When displaying a map of traffic incidents, conventional systemstypically use instead a single type of incident icon, and the user mustinquire further to determine the type and importance of the incident.Other conventional systems use no more than three or four differenticons, which is not as precise as in the present invention. Whendisplaying a list of incidents, conventional systems use a textualdepiction without displaying a specific icon representation for eachspecify type of incident. The system 10 as disclosed herein uses agraphical icon publisher, wherein classes of traveler information aredisplayed according to certain graphical icons. Non-limiting examples ofclasses of traveler information that may be grouped under a singlegraphical icon type are given above in Table 1.

Referring to FIG. 4 in a List of Incidents 402 graphically depicted inthe HTML language, and viewable using any HTML or Web browser, incidentsare displayed for each county with more severe incidents being displayedon the top.

When displaying a Map 401, the present invention uses larger GraphicalIcons 404 for more severe incidents, and typically uses more intense andsaturated colors for depicting more severe incidents. The system maythus represent a significant number of incident types such as ten,twelve .or more, and a viewer may readily assess the type and importanceof the incident with a single look at the overall Map 401. The iconsalso differ in shape: square, rectangle that is wider in the horizontaldirection, rectangle that is wider in the vertical direction.

Referring to a map in FIG. 4, the system 10 is capable of representing alarge number of incidents at the same time, as a large number ofincidents typically occur at the same time in a large metropolitan areasuch as the San Francisco Bay Area.

In preferred embodiments, Graphical Icons 404 on a Map 401 are alsodrawn in inverse order of severity: most severe (and larger) firstfollowed the least severe (smaller). In this way, if overlap occurs, thesmaller icons only partially obscure the larger ones and both arevisible.

When the user's mouse goes over an incident icon, detailed informationabout the incident is displayed on the user's computer screen. In caseof overlap, the most severe information is displayed. In preferredembodiments, this is achieved by listing the most severe informationfirst. In further embodiments, the size of the Graphical Icons 404 ingeneral may be reduced so as not to obscure other Graphical Icons 404,or the Map 401. In these embodiments, the size of each Graphical Icon404 may increased as a user points to the Graphical Icon 404, therebyenabling the user to obtain a better view of the graphic. This featuremay be used with, or without, the presentation of detailed information.

A conventional Cellular Phone 403 receiving traveler informationproduced and dispatched by the present invention is also shown on FIG.4. Using the Abbreviation Engine 186 of the Traveler InformationDispatcher 180, the most important information about the incident may beentirely displayed on the small screen of a conventional cellulartelephone, and this invention allows a user to understand the location,specific nature, begin and end time of an incident presumably affectingthe user in his or her traveling pattern.

Understanding the location, duration and nature of the incident does notrequire extensive manipulation or text scrolling of the Cellular Phone403.

FIG. 5 is exemplary of further aspects a preferred embodiment of theTraveler Data Publisher 170, including a Publishing Process 500. ThePublishing Process 500 is preferably invoked frequently, such as everyminute.

In Step 502, the Active Traveler Information Database 130 is beingsorted by county.

In Step 504, the incidents from the Active Traveler Information Database130 are sorted in decreasing order of severity, for a specific area,such as within a county.

The next incident from the Active Traveler Information Database 130 isretrieved in Step 506.

In Step 508, a graphical icon is chosen for an incident depending uponthe type, subtype and description of the incident. This is preferablyaccomplished by searching the type, subtype and description of theincident for keywords and keyword combinations that preferablycorrespond to a graphical icon. For instance “Collision” or “Accident”combined with “Ambulance” or “Injury” or “Injuries” typicallycorresponds to an INJURY ACCIDENT icon.

In Step 512, detailed information for an incident is determined usingthe incident's type, subtype, status, location, time, and detaileddescription. The detailed description is preferably displayed as a userpoints to the incident icon, for instance using a mouse or otherpointing device.

In Step 514, geographical coordinates for the incident are beingretrieved when available. If geographical coordinates are available anddesignate a location inside a map then Step 516 is executed next.Otherwise, Step 518 is executed.

In Step 516, an icon is being embedded in a map at a locationcorresponding to geographical coordinates. The location is determined byconverting latitude and longitude data to pixel (picture element)coordinates in the map. Latitude and longitude are converted using thelatitude and longitude at the map center, knowledge of how many pixelsin the map correspond to a degree of latitude and longitude deviation,and using conventional trigonometry. An icon is embedded at the pixelcoordinates by copying the icon into the map. Detailed information forthe incident is also being embedded in an html file. The system thenexecutes Step 518.

In Step 518, graphical icons are being chosen for routes intersecting atthe location of the incident. Graphical icons are determined by creatingan icon name from a route name; A route name is provided in the incidentlocation information. Then, it is determined whether the icon namecorresponds to an existing icon, in which case the icon is chosen.Otherwise no icon is chosen. As an incident location is typicallydescribed as an intersection of two highways, two graphical icons aretypically chosen.

In Step 520, an html table is prepared for formatting the variouselements of an incident information. The table allows to position anincident icon, route icons, the type of incident, and other incidentinformation in a manner suitable for clear exposition, as illustrated ina List of Incidents 402. Table gridlines are preferably invisible to theviewer.

In Step 522, formatted incident information is added to an html file,suitable for viewing.

In Step 524, if there are more incidents Step 506 is executed next andotherwise the Publishing Process 500 ends.

In some embodiments of the present invention, real-time or predictivetraveler information may be provided. This information may be utilizedin the context of, for example, routing whereby an optimal route issupplied to a user. The optimal route is dependent upon factors such asreal-time and/or predictive traffic congestion. This predictive data maybe representative of archived data over a variable window of time toreflect certain seasonal or other cyclical variations.

For example, forecasts may be generated for a given route based upon acalendar of events, the time and day of the week and/or sensor dataproviding the speed of traffic along portions of a particular road,highway or other thoroughfare. Through the combination of real-timespeed information with routing computations, a profile may be generatedwherein the expected travel time for any route for a reasonable periodof time is provided.

In such an embodiment, a routing engine may take into account real-timespeed information as well as predictive speed based upon calculationsderived from predictive congestion models as they relate to historicaland predicted traffic patterns. The routing engine may utilize anembodiment of the A* search technique (also referred to as the heuristicsearch technique). The A* technique uses estimates on distances to adestination to guide vertex selection in a search from the source. TheA* technique is further described in Microsoft Research Technical ReportMSR-TR-2004-24, the disclosure of which is incorporated herein byreference.

The present predictive traveling embodiment further utilizes a userinterface for selecting a start point, end point and any intermediatewaypoints. The user interface further allows for a determination ofwhether the routing engine should compute a fastest route or a shortestroute.

In the aforementioned routing engine, all road nodes and segments thatare relevant for routing are loaded into a shared memory. The sharedmemory overcomes the difficulties that the A* algorithm would otherwiseencounter in searching through a large number of road segments to findan optimal route, those road segments being fetched from a database.

Effective utilization of the A* algorithm further requires thespecification of a weight for each aforementioned road segment as wellas an estimate of the total weight to reach the destination. Exemplarysegment weights include segment length, segment travel time using asegment speed for a base map, segment travel time using speed fromreal-time traffic flow information (e.g., sensors, toll-tags and thelike), and segment travel time using predicted speed for a given day ortime of day. These segments weights are exemplary in nature and otherweights are envisioned as being within the scope of the presentinvention. Segment travel time is obtained by dividing segment length bysegment speed.

With regard to the aforementioned road segments, an array of historicalspeed measurements are maintained; for example, one for each ten minuteinterval in a day thereby resulting in 144 such intervals. Further,these intervals are maintained for each day of the week (seven suchdays), holiday departure and return dates (two such days) and otherpotentially meaningful days as they pertain to traffic conditions (e.g.,known road closures or special high-traffic events such as sportingevents. At least 144×9 historical speed values are maintained for eachsegment.

Each time a new speed measurement is available for a road segment, thatis, a sensor reading is obtained and validated to be a correctmeasurement, the historical speed value corresponding to that segment,10 minute interval and day is retrieved, and is updated according to thefollowing exemplary formula:historical_speed_value=(1−p)*historical_speed_value+p*new_speed_measurement.By adjusting the p value, the window of time for which thehistorical_speed_value pertains is influenced.

For example, with a new speed measurement available every three minutesand wherein p=0.02, three new speed measurements typically contributefor a given 10 minute interval. After one week, the influence of a newspeed measurement is multiplied by (1−p)³=0.94. After 4 weeks, the speedmultiplication factor is (1−p)¹² =0.78. After eight weeks, the factor is(1−p)²⁴=0.62. As such, a given speed measurement gradually loses itsrelevance over time and is replaced by newer speed measurements.

Certain embodiments of the present invention allow a timestamp to berecorded for each segment thereby recording the time of latest speedupdate. After a certain duration, the historical values for the segmentscan all be invalidated as they have become too old to be relevant and/oraccurate. In this manner, the historical speed values are typicallyupdated slightly every three minutes.

Due to the quantity of data to be processed, the update preferablyoccurs within computer memory rather than through accessing databasesoftware on storage media although data can be stored or backed up on aregular basis (e.g., once a day).

As shown in FIG. 6, using the historical values stored as explained, atravel time profile may be computed 600 as follows. In step 610, thestart and finish nodes of a route are retrieved. The routing algorithmis then used in step 620 to compute a route from start to finishincluding retrieval of an ordered list of road segments.

In step 630, on a given day for which a travel profile is requested, 10minute intervals are iterated. In step 640, the 10 minute intervals areconverted to a time of day. For example, interval zero might correspondto midnight while interval 143 would correspond to 10 minutes beforemidnight (i.e., 23:50).

In step 650, starting with a travel time of zero, the ordered list ofroad segments is iterated. For each segments, the time to travel thatsegment is computed by dividing the segment length with a historicalspeed value for that segment and corresponding to the current time ofday. In step 660, the resulting time to travel the segment is added tothe current time of day as well as pre-existing travel time.

In step 670, once the ordered list of segments is completely processed,the travel time is obtained. By repeating this process for each 10minute interval on a given day, a travel time is obtained for each suchinterval; this time can be graphed.

The end result is a routing computation wherein the followinginformation may be reported: (a) a route length; (b) an ideal tripduration if the selected route is un-congested, that is, prescribedspeeds on highways as reported in the aforementioned base map; and (c)real-time trip duration that takes into account current congestion.Congestion may be real-time or predictive based upon a particular timeof day (e.g., rush hour or traffic related to a particular event such asplanned construction, holiday traffic or a sporting event). An exemplaryrouting computation report interface 700 reflective of this informationis shown in FIG. 7.

The routing computation report interface 700 reflects a particular route710, the distance 720 to traverse that route, the current travel time730 and the ideal travel time 740. Route 710 may be titled based upon aparticular destination (e.g., Sacramento or Seattle) or the nature ofthe point-to-point route (e.g., home 2 work). Route 710 may also betitled based upon, for example, the actual route traveled (e.g., highwayCA-85). Distance 720 is the distance between the point of origin and thepoint of termination. Current 730 and ideal 740 travel times correspondto the reported information described above.

The routing computation report interface 700 further allows for thecreation of a new route or the modification of a pre-existing routethrough, for example, hyperlinks in an HTML-based interface.

FIG. 8A illustrates a route creation interface 800. In route creationinterface 800, a user is presented with a map 810 populated with points820 that may be utilized as a start, end or waypoint. Points 820 may berepresentative of highway ramps, mile markers, major cross streets orany other point wherein a destination may originate, terminate orpass-through. In an embodiment of the present invention, points 820 aredesigned to be representative of useful points for selecting a route(e.g., intersections of highways, cities or major landmarks).

The number of points 820 may increase based on the particularmagnification of the map 810. For example, a regional map may reflectonly a few points 820 whereas a city map may reflect a larger number ofpoints 820 in that particular points of interest as they pertain tostarting, terminating or passing-through on a particular journey aremore easily identified. Points 820 may be selected through the use of amouse (e.g., point-and-click) or through the use of a keyboard (e.g.,through tabbing) or via any other means of selection (e.g., through useof a stylus on a handheld device).

The particular map 810 displayed may be controlled through a drop-downmenu 830. Drop-down menu 830 may reflect a list of all available maps.In the present example, drop-down menu 830 reflects the selection of amap 810 of the Seattle, Wash. area. The route being generated throughthe selection of points 820 may be named through the use of naming tool840. The name of the route as provided through naming tool 840 willcorrespond to route 710 as illustrated in FIG. 7.

Route creation interface 800 further offers the ability to automaticallygenerate a return trip route through return trip selection tool 850without having to manually re-select points 820 in a reverse orderoffering added convenience to a user of interface 800. Once a user hasgenerated a route, named the route through naming tool 840 anddetermined whether they wish to automatically generate a return tripthrough return trip selection tool 850, the route may be saved byclicking on the <save> button 860. By clicking on the <save> button 860,the route will be uploaded to routing computation report interface 700.Alternatively, the route may be disposed of by clicking on the <cancel>button 870.

As a user navigates about the map 810, and more particularly points 820,in route creation interface 800, information corresponding to a highwayexit or other position may be rendered in the interface 800 as isreflected in FIG. 8B. Once two points 810 have been selected (selectedpoints 880), a route is computed by the routing engine from the firstpoint to the second point and displayed as a part of the selected route890 and also displayed on the map 810. If a user has utilized theaforementioned return trip selection tool 850, the second route isentered into the system simultaneously in the opposite direction oftravel.

As a user continues to select points (880), the last point 810 enteredalong the route is considered the destination with all otherintermediate points 810 deemed to be waypoints. Selected points 880 maybe promoted, demoted or even deleted as to alter the course of theroute. For example, in FIG. 8C, a selected route 890 is displayedwherein four selected points 880 are shown as a part of that route(SR-3, I-5, I-405 and SR-522). The numbering of those selected points880 is graphically illustrated on map 810. A promotion arrow next toeach selected point 880 offers promotion of the point whereas a demotionarrow offers alternative demotion of the selected point 880 as a start,destination or waypoint. A deletion ‘X’ offers the aforementionedability to eliminate a selected point 880 from the selected route 890.

Once a selected route 890 has been established through interface 800,the routing engine determines travel time by compounding the weights ofthe segments that compose the shortest or fastest route. Depending uponthe weights that are used (e.g., ideal speed, speed from real-timecongestion, speed from predicted congestion), different travel times maybe reported.

For example, in FIG. 9A, the selected route 890 is shown withcorresponding route title 710, distance 720 and travel time information:current 730 and ideal 740. As shown by the temporal disparity betweencurrent travel time 730 (2 h, 56 m and 40 s) versus ideal travel time740 (1 h, 47 m and 35 s), this route is by no means an expedient routedue to high traffic volume as may be indicated by road colorations 910.Road colorations 910 may be reflective of high traffic (e.g. redcolorations) or smooth, uninterrupted traffic flow (e.g. greencolorations). Not all points on selected route map 900 may evidence aroad coloration 910 as some portions of road or thoroughfare may notallow for calculation of real-time or predictive traffic conditions(e.g., no sensors or traffic reporting).

In the instance that the selected route 890 is not the fastest route, auser may presented with a <Show Fastest Route Tool> 920 as illustratedin FIGS. 9A and 9B. Upon selection of the <Fastest Route Tool> 920, therouting engine will re-calculate a route between the point of origin andselected destination and display the same as shown in the fastest routemap 930 of FIG. 9B. If the routing engine has already calculated thefastest route (e.g., in a parallel calculation with the selected route890), then the new route is merely displayed. In some embodiments, thefastest route (or certain portions thereof) may be overlaid with theselected route 890. It should be noted that in some instances, theshortest route may be the fastest route notwithstanding existing trafficdelays.

In some embodiments of the present invention, an alert may be sent to auser if the delay in a selected route 890 exceeds an optionaluser-specified threshold (e.g., 30 minutes more than the ideal time orcurrent travel time exceeds two hours total). Generation of the alertwould be a result of the routing engine continuously calculatingcongestion and travel times relative the user's selected route 890. Suchan alert may be sent to, for example, a cellular phone utilizing SMS orto a user's computer via an automatically generated e-mail message. Oncethe user is alerted as to the change in traffic conditions and/or traveltime, the selected route 890 may be altered (e.g., selection of thefastest route).

An alert interface 1000 is illustrated in FIG. 10A. A user is firstoffered the choice of a particular device 1010 where the alert is to besent. This drop-down menu may list a variety of devices such as ‘cell,’‘computer’, ‘PDA,’ pager’ and so forth. The user is then offered thechoice of determining to which route 1020 the alert will pertain. Forexample, a user may only be concerned with the travel route home fromwork so that they may be home in time for a family event. Routes 1020 asreflected in this drop-down menu would correspond to those routes 710previously referenced in FIG. 7. The user is further given the option ofreceiving alerts as they pertain to traffic conditions on particulardays 1030 and between particular times 1040 through a series of checkboxes and drop-down menus, respectively. The user is further given theoption to determine whether to be alerted as to particular incidents1050 or changes in travel speed 1060.

For example, particular incidents 1050 may be associated with severeincidents that might block a lane of traffic (e.g., an overturned semi)or of any and all incidents (e.g., stalled cards and/or minor fenderbenders). Alternatively, a user may wish to be alerted as to changes intravel speed 1060 regardless of the cause (i.e., the particular incident1050 causing the delay). In these instances, the user may wish to bealerted whenever their travel time changes by a particular time.

FIG. 10B illustrates an exemplary SMS message 1070 sent to a cellulardevice 1080, the message reflecting that the route identified as<work2home> has increased in travel time by a total of six minutes.

Further embodiments of the present invention allow for animated roadtraffic reports whereby realistic traffic animation based on real-timeflow and incidents are displayed to a user. Such animated road trafficreports may be mapped on satellite imagery in conjunction with thepublishing system described herein. An exemplary animated road trafficreport 1100 is illustrated in FIG. 11A.

The exemplary animated road traffic report 1100 illustrated in FIG. 11Acomprises satellite images 1110 of a traffic area 1120. Traffic area1120 may be, for example, a particular intersection of roads, highwaysor other transportation thoroughfares (e.g., train or subway tracks); aparticular area surrounding a city (e.g., a 20-square mile areasurrounding Sacramento, Calif.); or a particular traffic ‘hot spot’(e.g., a section of highway undergoing construction). Traffic areas mayalso be artificial areas of particular focus at a particular time. Forexample, a traffic area may begin as the aforementioned 20-square milearea surrounding Sacramento but may be enlarged/focused in with regardto a particular region in that 20-square mile region (i.e., an enlargedarea allowing for increased viewing ease). Traffic areas 1120 arereferenced in a non-restrictive sense and are meant to include anyparticular area wherein particular traffic patterns may be of presentinterest.

Satellite images 1110 of the traffic area 1120 may be acquired from anyvariety of sources. For example, satellite imagery may be obtained froma proprietary satellite orbiting the Earth. Satellite imagery may alsobe obtained directly from commercial satellites orbiting the Earth.Satellite imagery may also be obtained from commercial vendors withaccess to satellite equipment: Satellite imagery may also be obtainedfrom, for example, government entities such as the U.S. GeologicalSurvey or U.S. Department of Defense. The particular source of satelliteimagery is irrelevant so long as the satellite images 1110 of aparticular traffic area 1120 allow for the overlay of traffic animation.

Satellite image 1110 may be of varying detail. For example, certainsatellite images 1110 may provide detailed geographic information orsimply provide the most fundamental of satellite images. Satelliteimages may also be manipulated to aid in generating three-dimensionalinformation. For example, one-dimensional satellite images 1110 may beprocessed in the context of other geographical information (e.g.,altitude information) to generate a three-dimensional satellite imagethat reflects information along an X-, Y-, and Z-axis like the satelliteimage 1110 shown in the animated traffic report 1100 of FIG. 11A.

Animated traffic report 1100 further comprises thoroughfare images 1130.Thoroughfare images 1130 are computer-enhanced images that follow thenatural path of real-world traffic thoroughfares (e.g., roads, highways,subway, train, etc.). The textured three-dimensional representation oflandscape of the particular traffic area 1120 aligns with and providesthe three-dimensional coordinates for the roads (i.e., a thoroughfare)that are animated and overlaid on the satellite image 1110.

For example, animated traffic report 1100 illustrates a thoroughfareimage 1130 of Interstate Highway 5. This computer-enhanced image aidsthe viewed with regard to identifying, highlighting and following thecourse of Interstate 5 in that the satellite image 1110 by itself maynot provide a clear view of the highway, which may be the result of poorimaging, cloud cover or other atmospheric anomalies (e.g., smog or haze)or as may occur due to natural geographic formations (e.g., a roadtraversing a mountain and the particular angle of the satellite imagenot allowing for a top-plan view of the particular thoroughfare) ormanmade formations (e.g., tunnels through a mountain range). In someembodiments of the present invention, especially those with high-qualitysatellite images 1110, thoroughfare images 1130 may not be necessary.

Animated traffic report 1100 may also comprise thoroughfare identifiers1140. Thoroughfare identifiers 1140 identify particular thoroughfares orthoroughfare images 1130. For example, Interstate 5 is identifiedthrough a graphical representation of a readily recognized Interstatehighway sign with the appropriate highway number applied to the sign.Similarly, California State Highway 160 is identified by a thoroughfareidentifier 1140 resembling a readily recognized California state highwaysign with the appropriate highway number applied to the sign. Smallerthoroughfares (e.g., city streets, exits, specially named sections ofhighways or city streets) may also be associated with a thoroughfareidentifier 1140.

Thoroughfare identifiers 1140 may be rendered in such a way that theyresemble a street or highway sign that might be found in the real-worldrelative the particular thoroughfare. Thoroughfare identifiers 1140 neednot be limited to any particular format and may be adjusted to resemblethe particular signage format of a particular state or region or anyother format as may be desired by a party operating the present system.

Animated traffic report 1100 may also comprise structure identifiers1150. Structure identifiers 1150 are graphic representations of certainstructures within the traffic area 1120. For example, in FIG. 11A, theSacramento Capital Building and the Tower Bridge are rendered in thetraffic area 1110 as structure identifiers 1150. Structure identifiers1150 aid in providing context to the traffic map and variousthoroughfares in addition to improving the graphic realism of theanimated road traffic report 1100. For example, if a user were informedthat there exists a particular traffic condition on State Highway 160,this information is generally useless absent some sort of relativepositional context. If the user is shown the same traffic condition butnear a structure identifier 1150 representative of the State Capitol,this information may be of use to the user should they need to travel toor near the state capitol building.

In an exemplary animated road traffic report 1100, roads andthoroughfares are decomposed into segments and the average real-timespeed of traffic as provided by the various data sources of the presentinvention are mapped to the segment. For example, Interstate 5 mayconstitute a road segment. Further, particular portions of Interstate 5may constitute a road segment (e.g., the area between exit X and Y mayconstitute a first segment and the area between exit Y and Z mayconstitute a second segment). These road segments are then color coded1160 relative particular traffic data for that road segment.

For example, the southbound traffic area between 12^(th) Avenue andMartin Luther King Boulevard as illustrated in the present animated roadtraffic report is color coded red indicating slow traffic. NorthboundI-5, however, is color coded green indicating free moving traffic.Meanwhile, a portion of I-80 is color coded orange indicating a mildslow down but not to the extent of, for example, the slow down between12^(th) Avenue and Martin Luther King Boulevard, which is moreindicative of an accident. In some embodiments of the present invention,traffic, too, is color coded 1170.

The visualization of traffic conditions in the present animated roadtraffic report 1100 combines a traffic model, the current state oftraffic, as provided with speed measurements for the road segments and athree-dimensional representation of landscape comprising topographytextured with satellite or aerial imagery, as well as three-dimensionallandmarks.

The traffic model comprises a number of vehicles, which may berepresented abstractly such as through using triangles in FIG. 11A orusing faithful three-dimensional representations of a car like thoseshown in FIG. 11B. The vehicles are initially positioned along the roadsegments proportionally to the density of traffic if known. For eachframe of the animation, each Vehicle's position, speed and accelerationare being updated. Each vehicle's new acceleration is determined by thevehicle's current state, the current state of traffic for the segmentwhere the vehicle is located, and the acceleration, speed and positionof the vehicle ahead.

During the three-dimensional animated, certain rules are applied. First,if the distance to the next vehicle is less than a following distance,and the vehicle is moving faster than the next vehicle then the vehiclevisually decelerates. If the speed is otherwise below the segment speed,the vehicle visually accelerates. If the speed is above the segmentspeed, the vehicle visually decelerates. In all other instances, thereis no change in speed.

Acceleration and deceleration are computed by mitigating averageacceleration and deceleration with vehicle-specific random factors.Because real traffic has a random component, this randomization providesa realistic appearance to the traffic model and the resultingvisualization.

The traffic model is adapted to comply with the current trafficconditions whereby each vehicle's color is set to match the color of theroad segment on which it currently is located. Each vehicle's speed isinfluenced in the model so as to match the segment's speed as soon andas accurately as possible.

Vehicle's depicted in the animated traffic report 1100 may also be‘squashed’ and ‘stretched’ proportionally to correspond to accelerationor deceleration of the vehicle. These proportional adjustments arevisually intuitive with regard to the process of backing up to complywith a specific speed.

In yet another embodiment of the present invention, real-time trafficdata maybe combined with various routing capabilities to determinetravel times of common and alternative routes. In this manner, mapping,routing, and personal preferences may be integrated to enable efficientarchiving and time-series forecasting such that the travel time for aparticular route or series of routes may be forecast based upon observedconditions and other factors.

Through observing the mapping of common incidents and traffic flow,incidents are qualified with respect to the current travel time on aroute where the incident occurs and in the vicinity of the incident. Adetermination of whether the travel time is significantly affected fromusual travel conditions over that route is also made.

In the instance that an incident is determined to significantly affecttravel time, an embodiment of the present invention identifies orpromotes that incident to ‘significant incident’ status. The significantincident may be highlighted graphically and/or reported to users via,for example, e-mails, SMS messages and the like. Significant incidentsmay also be reported to traffic broadcasters in order to disseminatethat data to drivers who may not subscribe to the present system (e.g.,via a radio broadcast).

FIG. 12 is an exemplary graphic interface 1200 highlighting asignificant incident 1210. The hit-and-run incident reported at theintersection of I-405S and Getty Center Drive has been promoted to‘significant status’ as a result of the present system having correlateda slowdown in traffic patterns relative the reported incident. Thesetraffic patterns may be identified from a single source or a pluralityof sources.

An embodiment of the present invention will periodically review thetraffic patterns relative to the significant incident 1210 and determinewhether the incident still affects travel time. If the incident is nolonger adversely affecting travel time—adversity being a variabledeterminable by a user of the present system—the incident may be demotedto regular status and is no longer displayed on interface 1200, nor arereports delivered to users or other individuals. The nature of theincident, the period of time the incident affected travel flows and thedegree to which traffic was affected may all be recorded in a trafficdatabase.

With regard to generating traffic forecasts and trip advice, anembodiment of the present invention may access a data archive wherebyrecently observed traffic conditions are allocated to segments of roador highway. Utilizing this data format, a profile of trip duration for agiven route maybe generated for a specific time period, for example,seven days. This forecast may be based on recent history of speeds overthe route or particular segments of the route as well as other factssuch as weather forecasts and holiday traffic.

The travel time forecast may integrate speed forecasts for the entireduration of the trip as opposed to a forecast generated only at the tripstart time. For example, an embodiment of the presently described traveltime forecast may relate to a trip starting at 3pm and lasting 100minutes (i.e., 100 minutes of travel time). Instead of calculating onlytraffic value as they exist at 3pm, the present invention will considertraffic speed forecasts from 3pm to 4:40pm and apply those forecasts tothe relevant highway or road portions as they relate to the specificroute to be traversed by a user of the present system.

The presently described forecasting embodiment stores an array of speedfor, for example, ten minute intervals for each day of the week for eachroad segment in each direction of travel. In an embodiment of thepresent invention utilizing ten minute intervals, 2016 values would beallocated. As these are predicted speed values, the allocation of a fullprecision floating point number is not necessary. Data is recorded onlyfor segments that have speed sensors other speed data determining means(e.g., toll tags). If a speed value is not readily available, a defaultvalue may be utilized, the default value being calculated relative tosurrounding speed values or subject to a manual setting.

Based on the particular route selected by the user, a number of roadsegments will be identified. The forecast engine of the presentinvention will then generate a table of travel times for the route foreach 144 ten minute interval (i.e., 24 hours broken into 60 minutesfurther broken into 10 minute segments—(24*60)/10—in each day of theseven day week. The result is a table of 1008 pieces of unique routinginformation.

As shown in FIG. 13, for each element of routing information, a firstsegment is identified in step 1310 and a speed is forecast for the tenminute interval in step 1320. The travel time on that particular segmentis then calculated in step 1330. The next segment in the route is thenidentified in step 1340 and a speed is forecast for that segment usingthe appropriate ten minute interval, not earlier than the current tenminute interval, and, depending upon the time of day when that segmentis reached, the next incremental ten minute interval in step 1350. Thetravel time for this second segment based on the particular increment ofthe ten minute interval is then identified in step 1360. The travel timefor the first segment is then added to the travel time for the secondsegment in step 1370. The result is repeated until a travel time hasbeen allocated to each segment along the entire route and a final traveltime is calculated (step 1380).

Through this incremental speed-to-road segment determination, travelpatterns may be identified and illustrated graphically whereby users mayplan travel around peak times in order to optimize travel.

FIG. 14 illustrates an exemplary travel time forecast 1400 for aparticular route, specifically from Oakland, Calif., to Palo Alto,Calif., utilizing the aforementioned methodology. Travel time 1410 isreflected along the y-axis whereas time of day is reflected along theX-axis 1420. As can be seen by peak-traffic highlighting 1430,commencing travel from Oakland to Palo Alto between the times of 7.14amand 8.45am is not advised.

In one embodiment of the present invention, significant peaks of traveltime may be identified through a criterion wherein the maximum traveltime in the graph exceeds the minimum by a predetermined ratio, forexample, 25%. If the minimum is exceeded by the aforementioned ratio,then the travel time graph will accumulate temporal interest, on agraph, a horizontal line with a valuation equal to the peak value lessX% of that value. In one embodiment of the present invention, X is equalto 10. The resulting intersection is a sequence of pair values whereineach value pair determines a peak driving time (e.g., avoid driving aparticular route between a start and finish time).

If the two peak times are close to one another for a relativelytemporary period of time, they may be combined into a single peak. Forexample, a peak driving time of 4.40 to 5.50 and 6.00 to 6.24 may becombined into a single peak driving time of 4.40 to 6.24 because thepeak driving times are otherwise ten minutes apart. The temporary periodof time leading to a combination of peak times may be set by a user ofthe system.

One skilled in the art will recognize that the Traveler InformationDissemination system 10 as disclosed herein is susceptible to manyvariations and additional embodiments not described herein. Therefore,it is considered the teachings herein are only illustrative of theinvention, and not limiting of the invention in any way. For example,new traffic patterns may be recorded and observed utilizing themethodologies described herein.

1. (canceled)
 2. A method for predicting a travel time for a trafficroute, comprising: associating traffic speed data with a plurality ofroad segments for a particular time interval; determining a predictedtravel time for a plurality of road segments based on at least thetraffic speed data for the plurality of road segments during aparticular time interval, traffic speed data associated with theplurality of road segments during a particular time interval; publishinga predicted travel time for the traffic route, wherein the predictedtravel time includes a total travel time for each of the plurality ofroad segments making up the traffic route.
 3. The method of claim 2,wherein the publication of predicted travel time includes a graphicrepresentation of the road segments.
 4. The method of claim 3, whereinthe graphic representation of the road segments is three-dimensional.